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Transactor per AMIGA 



Ladri! 


Finalmente, è il caso di dirlo, mamma Commodore ha reso attivo anche in Italia il programma di supporto 
agli sviluppatori, cui avevamo accennato ne! reportage dello scorso numero sulla conferenza tenutasi a 
Francoforte. L'evento in sé potrebbe anche passare sotto silenzio se non fosse che si tratta di un chiaro 
indicatore di una certa volontà positiva che, negli ultimi tempi, anima la Realcasa dell'home computer. 
Ebbene, il fatto che sia venuto il momento di codificare una sorta di regolamento dello sviluppo hardware 
e software intorno ad Amiga, deve essere considerato solamente un fatto positivo. Come ci si potrà 
rendere conto leggendo il resoconto relativo all'evento a pag. 15, il programma di supporto non è 
perfetto, ma permette anche a noi italiani di combattere ad armi, quasi, pari con il resto degli sviluppatori 
Amiga sparsi per il mondo. 

Pur avendo infatti a disposizione gli stessi mezzi, ci resta da recuperare qualche anno di oscurantismo, 
qualche "briciolo" di cultura e soprattutto la mancanza di finanziamenti. Uno sviluppatore americano, 
inglese o tedesco, una volta che ha terminato il proprio prodotto, può cercare di piazzarlo sul proprio 
mercato, quello che conosce meglio e che gli è più facile raggiungere. Con i proventi derivanti dalle 
vendite in patria può cercare di espandere i propri orizzonti, distribuendo, magari anche adattando, il 
proprio prodotto in altri paesi. L'italiano, povero tapino, invece no. Non può sperare di avere alcun 
provento dagli utenti di Amiga del proprio paese. Pochi italiani hanno cercato fino a questo momento di 
distribuire propri prodotti in Italia e non si può certo dire che si siano arricchiti, né che abbiano 
recuperato i soldi spesi. Se a un produttore manca il supporto del proprio mercato cosa resta da fare, 
spostarsi su quello estero? 

I costi per distribuire all’estero sono però nettamente superiori (basti pensare ai soli trasferimenti) e 
inoltre gli stranieri sono molto diffidenti su quanto, d'informatico, arrivi dall'Italia. Non è poi da 
sottovalutare il fatto che la nostra cultura è differente da quella di altri popoli: chi garantisce che un gioco 
sui Promessi Sposi (tanto per dire) possa aver successo in un paese al di là delle Alpi? 

In sostanza, pur avendo a disposizione gli stessi mezzi, siamo distanti anni luce da una situazione minima 
che potrebbe garantire una vita florida a chi produce. Per uscire dalla situazione disastrosa in cui si trova 
il nostro paese non basta il '92, quando si realizzerà l'unione economica della CEE, ci vuole un 
cambiamento radicale nella mentalità degli utenti così come una legge seria e definitiva contro la 
pirateria software. I LADRI di software, come sarebbe più giusto chiamarli, togliendo quell'alone di 
romanticismo che gravita attorno alla figura del pirata, oltre ad aver rubato fior di miliardi ai legittimi 
proprietari, hanno rubato a tutti gli utenti e programmatori la possibilità di divertirsi e lavorare come tutti 
gli altri ne! mondo. 

Non si può infatti non addossare a questo malcostume (visto che non si può definire reato) la maggior 
parte delle responsabilità. Il peso di questa sconfitta nazionale, già visibile adesso, si pagherà più avanti 
quando sarà troppo tardi per porvi rimedio. Già ora fa rabbia vedere come paesi partiti, da un punto di 
vista informatico, forse più tardi di noi (tanto per non far nomi, la Francia) possano ora contare su 
strutture di sviluppo software di dimensioni ragguardevoli che esportano i loro prodotti, (tanto per non far 
nomi, la Infogrames francese), solo perché le loro produzioni sono tutelate. 

Ben venga quindi il programma di supporto per gli sviluppatori, purché non sia la sola azione di un 
entusiasta in un mare di indifferenza e mafia. 


Marco Ottolini 
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si hanno strane configurazioni di dischi. Questo sguardo 
approfondito al problema dovrebbe essere d’aiuto anche 
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Amiga. 
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ragionato del contenuto dei Fish Disk. Da staccare e 
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in ogni momento. 
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Un digitalizzatore audio dalle rare capacità. Il suo 
software può essere utilizzato anche con altri sistemi di 
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Betty ci mostra, con la consueta competenza, alcuni bug 
presenti nella versione 1.3 e altri problemi che si 
possono presentare a chiunque usi intensamente il 
proprio Amiga. 
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di Steve Simpson 

Steve.sviluppa il concetto di device per i programmatori 
avanzati, così come nello scorso numero aveva trattato 
le librerie. Mostrerà in dettaglio come creare un proprio 
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Lettere... 


Salve, vi scrivo per fare i complimenti alla vostra rivista che si 
occupa, finalmente, di una fetta di utenza sinora dimenticata, i 
programmatori. Ho letto l’articolo sul secondo numero della ri¬ 
vista che parlava di ARexx, un programma che mi interessa 
molto e sarei veramente intenzionato a reperire, ma una richie¬ 
sta diretta negli USA, mi sembra proibitiva. E possibile acqui¬ 
stare questo programma in Italia? Mi sembrerebbe opportuno 
inserire negli articoli che parlano di prodotti stranieri se questi 
siano reperibili in Italia ed in caso affermativo a chi rivolgersi. 
Augurandovi di continuare su questa strada, vi saluto con affet¬ 
to 

Fabrizio P. 

Il prodotto, se non indicato diversamente, non è da considerar¬ 
si direttamente disponibile in Italia. Questo perché la maggior 
parte dei programmi non lo sono. Purtroppo, è il caso di dirlo, 
nessuno pensa che programmi di questo tipo, cioè tutti quelli 
che non siano video giochi, possano avere un mercato anche 
in Italia. Ci sono due possibiltà: o ci si rassegna a provare a 
comprare all'estero, ringraziando i pirati, o si convincono i 
(pochissimi) distributori italiani che possono importare con fi¬ 
ducia anche in Italia. Naturalmente se qualcuno avesse già in¬ 
trapreso questa strada ce lo faccia sapere al più presto in 
modo da informarne tutti i lettori. 

...e Bit 


Innanzitutto vorrei complimentarvi con voi, oltre che per la ri¬ 
vista, per l'apparizione, sul primo numero, di alcuni articoli 
che mi sono sembrati particolarmente interessanti. Il primo è 
quello di Leonardo Fei sui Virus: l’antivirus Guardian è vera¬ 
mente eccezionale!! Grazie a lui ho finito per sempre di com¬ 
battere con i Virus e consiglio a tutti i possessori di Amiga 
1000 di procurarsi il Guardian-creator per installare il Guar¬ 
dian direttamente sul dischetto del KickStart. 

Un altro articolo che ha suscitato il mio interesse è 'Anteprima 
dell’AmigaDOS VI.3’. Leggendo infatti la parte dedicata al 
Fast File System e possedendo già il KickStart VI.3 ho deciso 
di fare alcune prove che considero interessanti e di cui ritengo 
opportuno informarvi: ho provato a installare il FFS sul drive 
esterno da 3" 1/2 dell’Amiga. Ho configurato appositamente sul 
WB il file devs/mountlist chiamando DF3: il nuovo device, ho 
inserito un disco nel drive, ho impartito il comando ’MOUNT 
DF3:' dell’AmigaDOS VI.3, ho formattato il disco con l’op¬ 
zione FFS (FORMAT DRIVE DF3: NAME prova FFS): ho in¬ 
fine aggiunto l’istruzione ADDBUFFERS DF3: 20 come da 
voi suggerito... ebbene? 

Facendo attenzione a non estrarre il disco dal drive (il FFS fun¬ 


ziona per ora solo con i device non rimuovibile come RAD e 
l’hard disk), tutto ha funzionato alla perfezione: ho effettuato 
numerose prove con il nuovo device e numerosi confronti con 
il drive DFO: con il file System normale ma ne ho tratto delu¬ 
denti conclusioni: è vero che la velocità è notevolmente au¬ 
mentata nella gestione della directory, dei comandi Dir, List, 
Delete, Renarne, ma è invece rimasta identica nel caricamento 
dei programmi e nella gestione dei file sequenziali e relativi 
che sono le cose più importanti. E vero che è stata migliorata 
l’organizzazione dei dati sul dischetto, che è stato recuperato 
altro spazio, ma è anche vero che tutto ciò è andato a discapito 
della compatibilità: il dischetto non può essere più letto da nes¬ 
sun dispositivo sul quale non sia stato preventivamente monta¬ 
to il FFS nel modo in cui ho detto in precedenza, pena la 
comparsa del messaggio "Not a DOS disk in unii 1"; inoltre lo 
stesso dispositivo (DF3:) sul quale il FFS è stato installato non 
può più leggere un disco formattato in AmigaDOS senza l’op¬ 
zione FFS, se non riferendosi (in questo caso) al device DF1 :. 
Spero che tutto ciò sia dovuto al fatto che il trackdisk.device 
sul KickStart non è predisposto (penso) al nuovo FFS, perché 
se questi inconvenienti non verranno risolti dalla nuova release 
del sistema operativo (V1.4) con la quale, si dice, il FFS sarà 
disponibile anche per i dischetti, si verranno a porre nuovi pro¬ 
blemi di compatibilità per il software, per i copiatori, per il di- 
skdoctor, per gli editor di tracce e per la maggior parte degli 
altri programmi di utilità generale che dovranno essere riadat¬ 
tati al nuovo sistema. Insomma, malgrado gli sforzi fatti dalla 
Commodore per ottimizzare le routine di gestione del drive, ri¬ 
tengo che il FFS non sia affatto superiore a un comune DI- 
SKARRANGER che, anche se effettua una velocizzazione 
solo su quanto già esistente sul disco, consente una lettura della 
directory e, in generale, una gestione del disco molto più effi¬ 
cace e veloce (basti guardare la rapida comparsa, da Wor- 
kbench, delle icone dei file all’interno delle finestre), 
mantenendo la completa compatibilità con tutte le versioni del- 
l'AmigaDOS!!! 

Ecco ora cosa si deve aggiungere nel file DEVS:MountList: 

DF3: Device = trackdisk.device 

FileSystem = L:FastFileSystem 

Unit = 1 

Flags = 1 

Surfaces = 2 

BlocksPerTrack = 11 

Reserved = 2 

Interleave = 0 

LowCyl = 0 ; HighCyl = 79 

Buffers = 20 

GlobVec = -1 

BufMemType = 3 

Mount = 1 

DosType = 0x444F5301 
StackSize = 4000 

Se non si vuole usare il drive normalmente chiamato DF1: bi¬ 
sogna modificare il valore di Unit. Quindi un utente di Amiga 
2000 che voglia usare il drive esterno dovrà scrivere Unit = 2, 
visto che normalmente quel drive si chiama DF2:. 

Fabio Caruso. Messina 
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I Servizi 

di 



Amiga Transactor offre una serie di servizi per agevolare i propri lettori nel reperimento di software e materiale utile alla 
programmazione. 

È disponibile l’intera libreria di dischetti di pubblico dominio curata da Fred Fish. Ogni dischetto contiene numerosi 
programmi e utility, spesso corredati da listati sorgenti e commenti degli autori. 

Per districarsi fra le centinaia di programmi disponibili nei dischi di Fred Fish, è stato creato un apposito catalogo di 20 
pagine. Tale elenco riporta, divisi per categoria e in ordine alfabetico, tutti i programmi presenti, completandoli con 
informazioni quali la descrizione della funzione, l’autore, il numero di versione, la disponibilità del sorgente e il disco nel 
quale sono contenuti. I dischetti possono essere ordinati contrassegnando i numeri desiderati, purché la quantità sia un 
multiplo di cinque. Per ordini amministrativi saremo costretti a non accettare ordini che non soddisfino questa regola. Tutto 
il materiale, a esclusione dei listati pubblicati sulla rivista, viene fornito nella versione originale americana, senza 
traduzione o modifiche. 

A ogni numero della rivista corrisponde un disco chiamato “AmiTrans Disk" che contiene tutti i listati pubblicati su quel 
numero, nonché i corrispondenti eseguibili e tutti gli altri programmi di pubblico dominio menzionati negli articoli. 


BUONO D’ORDINE 

Completa il buono d’ordine (o una sua fotocopia) e spedire in busta chiusa a: I servizi di Transactor per Amiga - Via Rosellini, 12 - 20124 Milano 

Si può allegare: assegno, contanti o fotocopia della ricevuta di versamento eie n. 11666203 intestato a Gruppo Editoriale Jackson. 

Non si effettuano spedizioni contrassegno 

Desidero ricevere i seguenti articoli; contrassegnare con una X i numeri di Fish disk desiderati (a gruppi di 5) 

Nota: Il disco 164 non è disponibile 
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DESCRIZIONE 

□ Fish Disk 

□ Catalogo 

□ AmiTrans Disk #1 

□ #2 #3 #4 


Lit. 35.000 per gruppo di cinque 
Ut. 15.000 aggiornato fino al Fish 138 
Lit 15.000 
Lit 15.000 


Cognome. 

Nome. 

Via . 

Cap. Città . 

Prov.Tel. .. 

Firma. 



(se minorenne quella di un genitore) 

Tutti i prezzi sono da intendersi IVA inclusa e spese di spedizione comprese. Gli ordini non firmati non verranno evasi. 
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I disk drive e le temporizzazioni 


Gli errori più frequenti e le procedure corrette 


di Bryce Nesbitt 

Questo materiale arriva dalla Commodore-Amiga Ine. ed è ap¬ 
parso su un numero di AmigaMail (TM). 

Parecchi tra gli sviluppatori software o hardware di aziende in¬ 
dipendenti impiegano i floppy disk drive in modo scorretto e 
realizzano cicli di attesa per le temporizzazioni in maniera del 
tutto inaccettabile. 

Vorrei farvi presente che l’uso del trackdisk.device è sempre la 
procedura più sicura per accedere ai dischi: se, però, per qual¬ 
che ragione avete proprio bisogno di operare direttamente sullo 
hardware o progettate hardware per i disk drive o avete biso¬ 
gno di piccoli cicli di attesa, allora è opportuno che leggiate 
questo articolo. Troverete, infatti,una discussione sulla maniera 
migliore di creare ritardi e dieci punti che chi programma con i 
dischi deve tener ben presente. 

La fonte di informazione più attendibile sulla temporizzazione 
dei drive è costituita dalla specifiche del costruttore. Questo ar¬ 
ticolo intende solamente porre in risalto gli errori più frequenti 
e grossolani. Rimane comunque consigliabile richiedere una 
copia delle specifiche tecniche di un disk drive e senz'altro la 
maggior parte dei distributori di componentistica non avrà pro¬ 
blemi a farvela avere. 

I dischi e il software 

Questa parte è indirizzata principalmente alle persone che scri¬ 
vono caricatori custom per i giochi. A causa di caricatori difet¬ 
tosi, ci sono migliaia di utenti Amiga che non possono caricare 
certi giochi e che pertanto NON POTRANNO MAI COM¬ 
PRARLI. 

Quindi... 

1: Non partite da presupposti errati. Ad esempio, se è necessa¬ 
rio che il motore del drive stia girando, accendetelo prima del¬ 
l'uso. Non assumete che il codice di boot venga eseguito con il 
disk drive o il sistema in uno stato prevedibile a priori. 

2: Non usate MAI un semplice ciclo con l’istruzione DBRA 
per la temporizzazione. C’è un gran numero di circostanze sot¬ 
to le quali questo sistema non fornisce affatto risultati accurati. 


L’argomento verrà comunque ripreso in seguito, nel paragrafo 
Come sprecare tempo. 

3: La linea STEP deve essere generalmente nello stato alto e 
deve essere attivata con un impulso basso. Prima, però, va pre¬ 
disposta la direzione con un’altra istruzione di scrittura nel re¬ 
gistro opportuno. Un modo corretto è il seguente: 


or.b #%00000010,$bfdl00 
and.b #%11111110,$bfdl00 
nop 
nop 

or.b #%00000001,$bfdl00 


/Predisponiamo 
la direzione 
/Diamo un 

impulso basso 
/Aspettiamo un 
attimo 

/ . . .un altro 

/Riportiamo 
alto STEP 


/— ora aspettiamo 3 millisecondi affinché 
/— la testina si porti sulla traccia 
/— successiva 


La Commodore-Amiga ha sempre specificato che lo sposta¬ 
mento della testina alla traccia successiva avviene entro tre 
millisecondi. Ciò non toglie che alcuni drive possano farlo 
molto più rapidamente e che altri invece diano dei problemi già 
sotto i 2.8 millisecondi. Quando poi si cambia la direzione, bi¬ 
sogna aspettare un minimo di 18 millisecondi in totale per te¬ 
ner conto anche del tempo necessario per la stabilizzazione 
(settling time) della testina. 

Si osservi inoltre che la linea TRACK ZERO non è valida fino 
a quando la testina non raggiunge effettivamente la traccia ze¬ 
ro. 


4: Quando fate partire il motore, aspettate che il segnale REA¬ 
DY vada basso prima di leggere o scrivere; gli spostamenti in¬ 
vece sono del tutto leciti durante tale intervallo. Si noti che 
READY ha significato solo quando il segnale del motore è 
ON. 

5: Per stabilire se c’è un disco nel drive, controllate il segnale 
DISKCHANGE; se tale segnale è basso, il disco è stato rimos¬ 
so dopo l'ultimo controllo (e magari anche reinserito). In tal 
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caso muovete la testina per aggiornare il segnale e esaminate lo 
stato ottenuto dopo questa operazione. 

6: Alcuni caricatori si servono di una traccia in più (o anche 
due) per mettervi dei dati o per le protezioni. Come Commodo- 
re-Amiga, non garantiamo che i drive che impiegheremo po¬ 
tranno sempre leggere più delle normali ottanta tracce. Diremo 
piuttosto che usare una traccia in più è abbastanza sicuro, due 
può ancora andare e tre è assolutamente un'idea molto azzar¬ 
data. 

7: Al termine di un'operazione DMA di scrittura sul disco, è 
necessario attendere 1.2 millisecondi prima di fare una qualsia¬ 
si operazione che coinvolga i drive (selezione, spostamento 
della testina e così via). 

Nel tipo di disk drive montato sulle nostre macchine la testina 
che cancella e quella che scrive o legge sono di poco separate. 
Il drive mantiene attiva la testina di cancellazione fino a qual¬ 
che istante dopo il termine della scrittura per compensare la 
presenza di questo "buco". Se non si attende il tempo sopra 
specificato si corre il rischio di scrivere su altre tracce o sull’al¬ 
tro lato del dischetto. 

Per quanto riguarda la parte hardware... 

8: La spia del drive non dovrebbe accendersi ad intermittenza 
durante l'accesso al disco. La spia dei nostri drive, infatti, spe¬ 
cifica lo stato del motorino. Tipicamente lo stesso segnale è an¬ 
che collegato alla linea IN_USE (pin 4). 

9: Per ragioni di compatibilità con i modelli futuri, i drive si 
devono rifiutare di spostare la testina oltre la traccia zero. Se la 
testina è sulla traccia zero e viene ricevuto una richiesta di spo¬ 
stamento verso l’esterno, la testina non deve muoversi; in ogni 
caso, lo stato del segnale DISKCHANGE deve essere aggior¬ 
nato, come avviene quando effettivamente la testina si sposta. 

10: Le specifiche che devono essere sempre rispettate per i no¬ 
stri drive da 90mm (3.5") sono le seguenti: 3ms per uno sposta¬ 
mento track-to-track, 15ms di tempo di stabilizzazione (settling 
time), allineamento radiale (misurato con il disco di allinea¬ 
mento Dysan) superiore all’80%, 500ms per ravviamento del 
motore e 800ms per l'accensione completa del sistema. 

Come sprecare tempo 

La maniera di gran lunga peggiore per inserire un ritardo in un 
programma per Amiga è la seguente: 

move.w #2000,dO 
loop: dbra loop,d0 

Eppure un gran numero di caricatori sfruttano sistemi simili 
per la temporizzazione dello spostamento della testina. Questo 
metodo è del tutto inaccettabile. 

I programmi che usano questo metodo non funzionano già oggi 
su alcuni Amiga e probabilmente non funzioneranno su tutti i 
futuri modelli Amiga. Purtroppo sono diversi i casi di pro¬ 


grammi che si rifiutano di caricare su macchine con particolari 
configurazioni. 

Se si intende preservare il sistema operativo multitasking, il ti- 
mer.device può essere impiegato per ottenere temporizzazioni 
che, nel frattempo, permettano ad altri task di girare. Se invece 
intendete impossessarvi della macchina, il metodo seguente è 
migliore: 

loop: btst.b #0,$bfed01 

beq.s loop 

In questa maniera si impiega uno dei timer ad alta velocità. Co¬ 
me potrete rendervi conto dall’esempio riportato al termine 
dell'articolo, i timer sono molto semplici da usare. 

Questo tipo di ciclo è migliore per vari aspetti; tra tutti spicca il 
semplice fatto che è più preciso. 

Il primo metodo mostrato non produce temporizzazioni accura¬ 
te in un gran numero di circostanze; la velocità, infatti, dipende 
dal tipo di CPU installata nel sistema, dal modo video, dal tipo 
di memoria in cui il programma risiede, dalle operazioni che il 
blitter sta magari compiendo, da quali interrupt sono attivi e da 
una varietà di altri fattori difficilmente controllabili. 

Il metodo che impiega i timer è più accurato e può essere atti¬ 
vato e dimenticato. Il timer fa tutti i suoi bravi conteggi e in¬ 
tanto il vostro programma può proseguire liberamente. Se 
necessario, il timer può produrre un interrupt quando ha finito 
o può attivare un bit che potete andare a leggere quando volete. 
Si può inoltre fare in modo che il timer ricominci automatica- 
mente a contare, una volta arrivato alla fine, così da produrre 
impulsi equidistanti, anche se il vostro software non riesce a ri¬ 
spondere immediatamente. 

Come calcolare gli intervalli di tempo. 

In primo luogo, vediamo alcune definizioni: 

1 millisecondo (ms) - 1/1000 di secondo 
1 microsecondo (us) = 1/1000000 di secondo 
1 nanosecondo (ns) = 1/1000000000 di secondo 

Su un Amiga con un normale 68000 senza memoria aggiunti¬ 
va, l'istruzione DBRA di cui abbiamo parlato in precedenza 
esegue in circa 1.5 microsecondi. Il ciclo del nostro esempio 
equivale ad attendere 3000 (2000* 1.5) microsecondi. 

Ogni 8520 contiene al suo interno due timer a 16 bit che opera¬ 
no un conteggio alla rovescia alla frequenza di 0.709379 MHz 
(su una macchina PAL) cioè con un impulso di clock ogni 
1.40968 microsecondi (con una macchina NTSC i valori sono 
rispettivamente di 0.715909 Mhz e 1.3968255 microsecondi); 
allora, per ottenere un ritardo di 3 millisecondi, dobbiamo ini- 
zializzare il contatore con il numero che si ottiene dividendo 
l'intervallo di tempo desiderato in microsecondi per 1.40968, 
cioè con 3000/1.40968 ovvero 2128. 

Ecco un esempio completo dell’uso del timer: 
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Dn esempio completo di temporizzazione con 
l'8520. Fa accendere e spegnere 
la spia dell'alimentazione ogni 3 millisecondi. 
Questo programma prende 

brutalmente possesso della macchina, per cui fate 
attenzione ! 


move.b #(2128>>8),ciaatahi ;e poi i 

; rimanenti nel contatore. 


; Aspettiamo che il timer finisca 
busy_wait: 





btst ,b 

#0,ciaaicr 

; Controlliamo 

Le frequenze a cui oscillano i 

quarzi in Amiga 


/il flag 

di fine conteggio 

sono : 

PAL 28.37516 MHz 


beq. s 

busy wait 



NTSC 28.318181 MHz 


bchg.b 

#1,$bfe001 

/Accendiamo o 






spegniamo la spia 

I due 

timer da 16 bit presenti 

in ciascuno degli 

bset.b 

#0,ciaacra 

; Facciamo 

8520 

contano ad un decimo 



/ripartire il timer 

della 

frequenza di clock della 

CPU (.709379 MHz 

bra. s 

busy wait 



ciaatalo 

EQU 

$bfe401 

ciaatahi 

EQU 

$bfe501 

ciaaicr 

EQU 

SbfedOl 

ciaacra 

EQU 

$bfee01 


in PAL). Ciò corrisponde ad 

un impulso ogni 1.40968 microsecondi. In una 
macchina NTSC la frequenza è 
leggermente superiore (.715909 MHz). 

Per aspettare 1/100 di secondo ovvero 10000 
microsecondi, il contatore- 
timer va inizializzato con il valore 
10000/1.40968 = 7093. 

Per 3 millisecondi, invece, il valore richiesto è 
3000/1.40968 = 2128 

Per ulteriori chiarimenti sugli 8520 consultate 
il Manuale hardware 


; Parte bassa del 
/Timer A 
/Parte alta del 
/Timer A 
/ Interrupt 
/control register 
/Byte di controllo 
/del Timer A 


move.w #$7fff,$dff09a /Blocca tutti 

/gli interrupt gestiti dai chip custom 

Inizializzazione/ viene fatta solo una volta. 
Predisponiamo il Timer A in 
modo one-shot. 

move.b ciaacra,d0 /Leggiamo il 

/registro di controllo di A 
and.b #%11000000,dO /Non tocchiamo 

/il flag 60/50Hz 
or.b #%00001000,dO ;o i bit di 

/direzione della seriale 
move.b d0,ciaacra 

move.b #%01111111,ciaaicr /Spegniamo 

/tutti gli interrupt dell'8520 

Predisponiamo l'intervallo di tempo desiderato 

move.b #(2128&255),ciaatalo /mettiamo 

/gli 8 bit meno significativi 


Errata corrige 


Per un banale errore, a pagina 68 del numero scorso, 
non era presente la figura ma solo la sua didascalia. 
La pubblichiamo ora, scusandoci con i lettori 
per l'accaduto. 


-► 


Library Routine 1 


Library Routine 2 


Jump Vector to 2nd Routine 


Jump Vector to Ist Routine 


Library Structure 


Library Data Area 


Library 
■ Base Address 


Increasing 

RAM 

addresses 


Figura 1: La relazione tra le componenti 

di una run-time library e le routine della library stessa. 
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La struttura di un programma Amiga 


Diamo un occhiata ravvicinata agli hunk 


di Jim Butterfield 

Jim Butterfield è uno scrittore, programmatore e professore di 
Toronto. Il suo interesse nei computer risale agli anni del 
KlM-1 da IK, nei giorni primordiali della Commodore. L’abi¬ 
lità particolare di Jim nel trasmettere la sua conoscenza enci¬ 
clopedica dei prodotti CBM attraverso articoli, libri, lezioni e 
programmi televisivi ha reso il suo nome famoso fra tutti gli 
utenti Commodore nel mondo. 

Sembra che un programma per computer (spesso chiamato tool 
nel gergo del Workbench) sia una cosa semplice. Un program¬ 
ma viene spesso descritto come una serie di istruzioni che svol¬ 
gono un determinato lavoro. In realtà ce n’è più di quanto non 
sembri dalla definizione. 

Il nostro programma, chiamato hunker, ci permette di esamina¬ 
re la complessa struttura dei programmi. È scritto in BASIC in 
modo che sia comprensibile a tutti e non sia necessario un co¬ 
stoso compilatore per farlo girare. Se volete vedere come fun¬ 
ziona è molto semplice chiedere un LIST e vedere cosa 
succede. 

I tre elementi 

Un programma tipico è costituito da tre elementi. Primo, il co¬ 
dice: le istruzioni che fanno funzionare il programma. Succes¬ 
sivamente, ci sono le costanti: valori fissi e messaggi usati dal 
programma. Infine, ci sono le variabili: valori che sono calco¬ 
lati mentre il programma è in esecuzione. 

Sembra che in BASIC questi tre tipi siano mischiati insieme. 
Un comando come PRINT J+5 contiene senza dubbio un’istru¬ 
zione. ma contiene anche una costante (il valore 5). Sembra an¬ 
che che contenga una variabile, J, ma in effetti ciò non è vero; 
il valore reale di J è memorizzato da qualche altra parte, sepa¬ 
ratamente dal programma. 

Molto di quello che viene considerato stile nei programmi in 
linguaggio macchina è il risultato di una attenta pianificazione 
delle zone riservate alle costanti e di quelle riservate alle varia¬ 
bili. 

Un programma stampa, per esempio, il messaggio ATTENDE¬ 
RE PER FAVORE in due momenti separati dell’esecuzione? Il 




programmatore immagazzinerà la stringa una volta sola e poi 
farà in modo che le due parti del programma vi accedano. Bi¬ 
sogna mettere a zero il contenuto di quindici variabili a un cer¬ 
to punto del programma? Il programmatore probabilmente le 
metterà una vicina all’altra e affiderà il compito di metterle a 
zero contemporaneamente a un semplice loop che pulisce la 
memoria. Spesso è vero che si investe molto più tempo nel pia¬ 
nificare le strutture dati che nello scrivere il codice vero e pro¬ 
prio. 

La struttura dei programmi per Amiga è stata concepita in ori¬ 
gine per tenere questi tre elementi separati, suddividendoli in 
hunk (pezzi) separati. Ci sono quindi tre tipi di hunk: le istru¬ 
zioni vengono memorizzate in un code hunk, le costanti in un 
data hunk e le zone riservate alle variabili in un BSS hunk (Ba¬ 
se of Stack Segment = inizio della zona di stack). Quest’ultimo 
tipo di hunk, quando viene memorizzato su disco, non contiene 
dati, ma solo le dimensioni dello spazio che sarà necessario ri¬ 
servare al momento del caricamento in memoria. Le variabili 
che ricadono in quest’ultimo tipo di hunk verranno inizializza- 
te dal programma mentre questo sarà in esecuzione. 

BSS è una sigla che viene dal mondo UNIX e le parole Base of 
Stack Segment non hanno alcun significato pratico su Amiga. 
Preferirei usare una traduzione ben più vecchia, proveniente 
dalle macchine precedenti, e pensare a BSS come Block Seg¬ 
ment Size (dimensioni del segmento). 

In origine fu stabilito che i programmi avrebbero dovuto conte¬ 
nere uno per ciascuno dei tre tipi di hunk. In realtà ce ne sono 
di più; molti programmi sono composti a loro volta da pro¬ 
grammi indipendenti o da routine collegate insieme. Vogliamo 
fare qualche calcolo? I programmi per svolgere questo compito 
verranno probabilmente richiamati separatamente (hunk e tutto 
il resto) e collegati (tramite il linker) al nostro codice. Il nostro 
programma, inoltre, potrebbe essere preceduto da del codice di 
startup già pronto, generalmente inserito in maniera automatica 
dal compilatore. E molto facile che un comune programma fi¬ 
nisca per essere composto di almeno una dozzina o più hunk. 
Come potete immaginare, il programmatore principiante, che 
utilizzi il C o il linguaggio macchina, potrebbe avere qualche 
problema a trovare il suo piccolo pezzetto di codice in mezzo 
alle masse di materiale extra che sono state aggiunte. 
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Il caricamento in ordine sparso (scatter loading) 

Sui computer più semplici (per esempio il C64), un programma 
è composto da un pezzo unico. L’operazione di caricamento 
trasferisce questo pezzo in una zona di memoria e il program¬ 
matore spesso sa anche in anticipo dove si trovi esattamente 
questa zona. 

Su Amiga la storia è differente. Un programma può essere co¬ 
stituito da un gran numero di hunk. Il programma verrà carica¬ 
to in ordine sparso , dove questo significa che ogni hunk verrà 
sistemato individualmente, durante il caricamento, in una parte 
della memoria disponibile completamente separata dalle altre. 
Il programma di caricamento che sovrintende a questa opera¬ 
zione si preoccuperà anche di stabilire i collegamenti necessari 
fra i vari hunk. 

Noi non dobbiamo preoccuparci di nessuna di queste cose. 
Amiga si prende cura di tutti i dettagli al posto nostro e noi non 
ci renderemo neanche conto che il nostro programma è fram¬ 
mentato in dozzine di pezzi sparpagliati per tutta la memoria. 
Tutto funziona insieme magnificamente. 

Ogni volta che un hunk fa riferimento a un altro hunk, per 
prendere o depositare dei dati o per chiamare una subroutine, 
questo fatto viene annotato in una tabella di rilocazione (relo¬ 
cation table). La tabella aiuta il programma caricatore (loader) 
a sistemare gli indirizzi in modo che puntino al posto giusto. 
Questo è una dettaglio tecnico: dal momento che tutti gli indi¬ 
rizzi usati in questo modo sono contenuti in longword da 32 
bit, la tabella viene chiamata RELOC_32. Vedremo parecchie 
di queste tabelle quando proveremo il programma hunker. 

Perché usare gli hunk? 

Questo tipo di caricamento in ordine sparso presenta molti van¬ 
taggi. 11 fattore più importante è il migliore utilizzo della me¬ 
moria. Supponiamo, per esempio, di avere un programma di 
50K. Se fosse composto unicamente di un pezzo, dovremmo 
trovare 50K di memoria libera contigua per poterlo caricare. 
Ma se questo programma fosse composto da dieci hunk, ognu¬ 
no di 5K, avremmo molti meno problemi a trovare lo spazio 
per caricarli tutti. 

Ci sono due tipi di memoria in Amiga: chip e fast (a meno che 
non possediate un A2000 con 1 Mega o una espansione per 
A500, avrete normalmente a disposizione solo 512K di memo¬ 
ria chip). I dati che vengono utilizzati dai chip audio/video 
(Paula-Agnus-Denise o PAD) devono essere scritti in memoria 
chip, in quanto questa zona è Tunica che i chip possono 'vede¬ 
re’. Tutto quello che non deve essere utilizzato da questi chip è 
meglio che venga scritto in memoria fast, se questa è disponi¬ 
bile, in quanto quest'ultima è più veloce. 

Ogni hunk di un programma può essere etichettato a seconda 
del tipo di memoria nel quale dovrà essere caricato. Se un hunk 
viene etichettato CHIP, per esempio, verrà caricato solo in me¬ 
moria chip. Se, invece, l’hunk non contiene indicazioni specifi¬ 
che sulla sua destinazione, verrà caricato in memoria fast, ove 
fosse disponibile, oppure in memoria chip. Nel raro caso in cui 


un hunk sia marchiato FAST, questo verrà caricato esclusiva- 
mente in tale tipo di memoria. Un programma contenente que¬ 
sto tipo di hunk non può girare su un Amiga provvisto solo di 
512K di chip ram. 

Possiamo a questo punto immaginare cosa succede quando un 
grosso programma (diciamo 200K) viene caricato in un Amiga 
dotato di espansione di memoria. Alcuni hunk, quelli classifi¬ 
cati CHIP, vengono caricati in memoria chip, mentre tutti gli 
altri vengono caricati nella memoria fast. Risultato: la memoria 
chip non viene sprecata, lasciandone una buona parte libera, e 
il programma gira più velocemente in quanto le istruzioni risie¬ 
dono in memoria fast. 

Si parte! 

Digitate il programma hunker; è scritto in AmigaBASIC. Sal¬ 
vatelo e date il RUN. Possiamo, a questo punto, specificare il 
nome di qualsiasi programma eseguibile. Il comando LINE IN¬ 
PUT ci permette di usare i caratteri come il due punti o la vir¬ 
gola senza creare confusione nell’interprete BASIC. Uno dei 
miei programmi favoriti è: 

DFO:c/BindDrivers 

Possiamo dare molte risposte alla domanda del programma 
VUOI VEDERE I BYTE? Rispondendo YES vedremo la 
stampa dei byte contenuti, mentre NO produrrà solo la lista de¬ 
gli hunk presenti. Rispondendo D o DATA otterremo la stam¬ 
pa dei soli hunk di tipo DATA (dove potremmo riconoscere le 
stringhe del programma) mentre A o ALL produrrà anche il 
contenuto delle relocation table. In generale queste ultime due 
opzioni non sono molto utili. 

Potreste essere sotpresi nel vedere qualcos’altro in alcuni pro¬ 
grammi: i simboli. Questi sono i nomi usati dal programmatore 
o dal sistema operativo per identificare determinate parti di co¬ 
dice. Questi simboli non sono più necessari dopo che le opera¬ 
zioni di compilazione/assemblamento e link sono state 
effettuate. Sono lì solo per aiutare nel debugging del program¬ 
ma. 

Durante le vostre esplorazioni di vari programmi e comandi, vi 
meraviglierete di certo per le grandi differenze nel numero di 
hunk che compongono un programma. Alcuni piccoli program¬ 
mi (come BindDrivers) usano molti hunk. Alcuni programmi 
di dimensioni medie (come Echo) non ne utilizzano quasi nes¬ 
suno. Il programmatore controlla gli hunk prodotti durante la 
compilazione e il link del proprio programma. In fondo si tratta 
anche di una faccenda di stile. 

Buona ricerca! 

Abbiamo forse bisogno di sapere quello che è stato appena det¬ 
to? Non direttamente. I programmi continueranno a funzionare 
bene sia che noi si sappia o meno dell’esistenza degli hunk. 

In ogni caso, è sempre interessante vedere il funzionamento in¬ 
terno del nostro computer. Una comprensione migliore sulla 
struttura di un programma, prima che questo venga caricato 
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dalla macchina, può darci più idee su come usare un debugger 
(come WACK) per vederne il funzionamento interno. 

PRINT#2,"a"; 1 

Ask=0:IF View>l THEN Ask=l 

GOSUB Dump 

Le idee che trarremo giocando con HUNKER ci aiuteranno a 
prepararci al giorno in cui ci tufferemo in linguaggi di pro¬ 
grammazione più avanzati e in una più seria programmazione 
di Amiga. 

WHILE NOT EOF(1) 

t$=INPUT$(1,1) 

h$=INPUT$(3,1) 

HunkType$="" 
p=ASC(t$)/64 

IF pOINT (p) THEN PRINT "?" 

PRINT "Hunk Analysis Program - J Butterfield" 

PRINT "v0.2 December 88" 

IF p=l THEN HunkType$=".CHIP" 

IF p=2 THEN HunkType$=".FAST" 

PRINT 

IF p=3 THEN HunkType$=".???" 

PRINT "nome del file eseguibile? "; 

LINE INPUT f$ 

GOSUB Eval 

IF ValuS=1001 OR Valu&=1002 THEN 

OPEN fS FOR INPUT AS #1 

PRINT#2,"Hunk";Hunk; 

length=LOF(1) 

PRINT f$ ;":";length;"bytes : " 

IF length>8 THEN 

h$=INPUT$(4,1) 

Hunk=Hunk+l 

IF Valu&=1001 THEN 

Ask=l:PRINT#2,"HUNK.CODE";HunkTypeS 

END IF 

GOSUB Eval 

IF ValuS=1002 THEN 

IF Valu&=1011 THEN 'hunk header 

Ask=2:PRINT#2,"HUNK.DATA";HunkType$ 

PRINT "vuoi vedere i byte? "; 

LINE INPUT x$ 

END IF 

h$=INPUT$(4,1) 

'view = 0 non visualizza i byte 

'view = 1 byte di dati e hex 

'view = 2 tutti i byte, solo dati hex 

GOSUB Eval 

size=Valu& 

IF View=0 OR View=3 THEN Ask=View 

'view = 3 tutti i byte, tutti gli hex 

View=2 

GOSUB Dump 

ELSEIF Valu&=1003 THEN 

IF x$="n" OR x$="no" THEN View=0 

PRINT#2,"Hunk";Hunk; 

IF x$="d" OR x$="data" THEN View=l 

Hunk=Hunk+l 

IF x$="aV OR x$="all" THEN View=3 

h$=INPUT$(4,1) 

PRINT "mando l'output alla stampante? "; 

LINE INPUT x$ 

GOSUB Eval 

PRINT#2,"HUNK.BSS.";pub$;" [ ";size; 

dev$="scrn:" 

"long words,"; sizeM; "bytes ] " 

IF x$="y" OR x$="yes" THEN dev$="prt:" 

OPEN dev$ FOR OUTPUT AS #2 

ELSEIF Valu&=1004 THEN 

h$=INPUT$(4,1) 

PRINT#2,"File :";f$ 

GOSUB Eval 

h$=INPUT$(4,1) 

WHILE Valu&OO 

GOSUB Eval 

size=Valu& 

unl=Valu& 

h$=INPUT$(4,1) 

WHILE unl>0 

GOSUB Eval 

PRINT#2, "Nome dell'unita' = ";INPUT$(unl*4,1) 

hk=ValuS 

h$=INPUT$(4,1) 

PRINT#2,"..HUNK.RELOC_32 Hunk";hk; 

GOSUB Eval 

IF View<2 THEN 

unl=Valu& 

Ask=0 

WEND 

ELSE 

PRINT#2,"HUNK HEADER "; 

PRINT#2,"vettori :" 

showcnt=0 

Ask=l 

h$=INPUT$(4,1) 

END IF 

GOSUB Eval 

GOSUB Dump 

size=Valu& 

h$=INPUT$ (4,1) 

PRINT#2,"Dimensioni"; size; 

GOSUB Eval 

h$=INPUT$(4,1) 

WEND 

GOSUB Eval 


Hunk=Valu& 

ELSEIF Valu&=1008 THEN 

PRINT#2," Da";Hunk; 

PRINT#2,"..HUNK.SYMBOL" 

h$=INPUT$(4,1) 

h$=INPUT$(4,1) 

GOSUB Eval 

GOSUB Eval 

l=Valu& 
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WHILE Valu&>0 

END IF 

length=Valu& *4 
nam$=INPUT$(length,1) 
WHILE MID$(nam$,length,1) 
length=length-l 

PRINT#2,” " ; 

FOR k=l TO 4 

=CHR$ (0) kO=ASC(MID$(h$,k,1)) 

IF Ask>l THEN 

WEND 

IF k0>31 AND k0<127 THEN 


PRINT#2," [";LEFT$(nam$,length);"] tx$=tx$+CHR$(kO) 

SPACE$(30-Xength); ELSE 


h$=INPUT$ (4,1) 

tx$=tx$+"." 

showcnt=0 

END IF 

GOSUB nshow 

END IF 

PRINT#2, 

k%=INT(kO/16) 

h$=INPUT$(4,1) 

GOSUB byteshow 

GOSUB Eval 

k%=k0-k%*16 

WEND 

GOSUB byteshow 

NEXT k 

ELSEIF Valu&=1010 THEN 

showcnt=showcnt+l 

PRINT#2,"..HUNK.END" 

END IF 

ELSEIF Valu&=1013 THEN 

NEXT j 

' not sure about this one 

IF Ask>0 THEN 

PRINT#2,"..HUNK.OVERLAY" 

WHILE showcnt<=4 

h$=INPUT$(4,1) 

PRINT#2,SPACE$(9); 

GOSUB Eval 

showcnt=showcnt+l 


Ask=View:IF Ask>l THEN Ask=Ask-l WEND 


size=Valu& 

PRINT#2,tx$ 

GOSUB Dump 

ELSEIF Valu&=1014 THEN 

ELSE 

PRINT#2," [ ";size;"long words,";size*4 ; 

PRINT#2,.HUNK.BREAK" 

"bytes ]" 

ELSE 

END IF 

CLOSE #2 

RETURN 

OPEN "scrn:" FOR OUTPUT AS 

#2 

PRINT Valu& 

nshow: 

PRINT "diagnostica:" 

FOR j=l TO 12 
h$=INPUT$(4,1) 

PRINT#2," "; 

PRINT#2, "["; 

FOR k=l TO 4 

GOSUB nshow 

kO=ASC(MID$(h$,k,1)) 

NEXT j 

STOP 

k%=INT(kO/16) 

GOSUB byteshow 

END IF 

k%=k0-k%*16 

WEND 

GOSUB byteshow 

CLOSE #2 

NEXT k 


ELSE PRINT#2 

PRINT "non e' un programma eseguibile" RETURN 


END IF 


ELSE 

byteshow: 

PRINT "troppo corto" 

t%=k%:IF t%>9 THEN t%=t%+7 

END IF 

PRINT#2,CHR$(t%+48); 

CLOSE #1 

RETURN 

PRINT 


END 

Eval : 

Valu&=0 

Dump: 

showcnt=0:tx$=" " 

FOR k=l TO LEN(h$) 

Valu&=Valu&*256&+ASC(MID$(h$,k,1)) 

FOR j=l TO size 
h$=INPUT$(4,1) 

NEXT k 

RETURN 

IF Ask>0 THEN 


IF showcnt>4 THEN 


showcnt=0 


PRINT#2,tx$ 

□ 

tx$=" " 
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Programma di supporto agli 
sviluppatori 


Commodore Italiana 

Riceviamo direttamente dalla Commodore Italiana il testo che 
annuncia l’inizio del piano di supporto agli sviluppatori Amiga 
cui avevamo accennato nello scorso numero. Riportiamo il te¬ 
sto integralmente ponendo solo un breve commento alla fine. 

Il concetto 

Nell’ottica di promuovere lo sviluppo di software, schede ag¬ 
giuntive e periferiche per Amiga. Commodore Italiana ha im¬ 
plementato un Programma Supporto Sviluppatori, sotto il 
diretto patrocinio di Commodore International. 

Lo scopo di questo servizio è quello di mettere a disposizione 
delle società o dei singoli impegnati attivamente nello sviluppo 
HW/SW per Amiga un ambiente che fornisca tutti gli elementi 
di supporto necessari: 

• Una pronta e completa diffusione di informazioni tecniche 

• la possibilità di acquistare materiale a prezzi particolari 

• dei mezzi di comunicazione rapidi ed efficaci 

• l’accesso diretto a nuove versioni di software e hardware 
nel periodo di beta-testing 

• la creazione e il coordinamento di contatti con editori ita¬ 
liani e stranieri 

Questo Programma di Supporto viene implementato a livello 
internazionale da Commodore International, che ha stabilito 
una rete di collegamento tra tutte le filiali Commodore nel 
mondo, le quali offriranno il loro proprio servizio di supporto 
locale. Tutti gli ambiti locali sono quindi collegati tramite mez¬ 
zi elettronici tra loro e con i relativi uffici guida europei e ame¬ 
ricani. Questa rete permette quindi un contatto privilegiato e 
diretto con le persone che hanno progettato l’Amiga e il suo 
System software, in modo da poter rapidamente rispondere ai 
quesiti tecnici. 

I servizi offerti da Commodore 

Abbonamento ad Amiga Mail e Amiga Mail Market 

Queste newsletter si occupano rispettivamente degli aspetti 
tecnici e di diffusione prodotti, con cadenza bimestrale. 

Già note nel mondo per la loro peculiarità, riportano informa¬ 
zioni spesso vitali per gli sviluppatori. 


Uno sconto sugli acquisti 

Per tutti i prodotti della linea Amiga verrà praticato uno sconto 
differenziato a seconda della categoria di appartenenza degli 
sviluppatori. Le uniche condizioni poste sono: 

• impegno a non rivendere il materiale nei 12 mesi seguenti 
la data d’acquisto 

• acquisto massimo di 2 pezzi per tipo per anno fiscale 

• pagamento contrassegno 
Accesso alla libreria sviluppatori 

Commodore fornirà una libreria di dischetti con i migliori 
esempi ed utility di pubblico dominio, possibilmente con i sor¬ 
genti. 

Supporto diretto 

Possibilità di contatto diretto telefonico per quesiti che richie¬ 
dano risposte urgenti. In particolare la possibilità di avere in 
breve tempo informazioni tecniche specifiche grazie al contat¬ 
to privilegiato con l'Engineering. 

Documentazione sul Sistema Operativo 

Uno sconto sull’acquisto della documentazione di riferimento 
del Sistema Operativo: 

- AW ROM Kernel: Exec 

- AW ROM Kernel: Libraries & Devices 

- AW ROM Kernel: Includes & Autodocs 

revised & updated 

- A500/A2000 Technical Reference Manual 

Accesso all’ulteriore documentazione tecnica: 

- Software Toolkit 

- IFF Manual & disks 

- Note delle Developer's Conferences 

- AmigaDOS 1.3 Native Developer Kit 

Documentazione tecnica hardware 

Possibilità di acquisto di manuali per l’assistenza, schemi e 
bollettini tecnici. 
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Parti di ricambio 

Possibilità di acquisto di parti di ricambio custorn con lo scon¬ 
to del 15% sul prezzo di listino, a queste condizioni: 

• limitato alle parti relative al progetto in corso di sviluppo 

• impegno a non rivendere il materiale 

• quantitativi limitati e comunque soggetti a verifica da parte 
di Commodore Italiana 

• pagamento contrassegno 
Beta-Test Software 

Commodore migliora incessantemente la funzionalità del Si¬ 
stema Operativo. Nell’ottica di verificare la compatibilità dei 
nuovi progetti e di orientare lo sviluppo in modo da trarre il 
massimo profitto da nuove versioni del System Software, sarà 
consentito l'accesso alle versioni Alpha e Beta. Naturalmente, 
la disponibilità del software sopracitato sarà subordinata ad un 
formale impegno di non divulgazione e di rapida informazione 
verso Commodore dei risultati di questi test. 

Beta-Test Hardware 

Commodore mette a disposizione degli sviluppatori la possibi¬ 
lità di accedere a nuovi modelli di Amiga e di periferiche in 
modo da poter testare il nuovo hardware e indirizzare i nuovi 
progetti in accordo alle piattaforme disponibili in futuro. La 
prova di queste apparecchiature sarà fatta presso la sede della 
Commodore Italiana su appuntamento, e sarà soggetta ad im¬ 
pegno di non divulgazione. 

Nei limiti del possibile, e quando la situazione lo richieda ef¬ 
fettivamente, Commodore Italiana potrà prestare per un perio¬ 
do limitato Thardware in beta-testing. 

Accesso gratuito a BIX 

BYTE Information Exchange (BIX) è il mezzo di comunica¬ 
zione privilegiato degli sviluppatori Amiga. Agli sviluppatori 
commerciali viene offerta gratuitamente l’opportunità di parte¬ 
cipare alla conference amiga.com, condotta da CATS (Com- 
modore-Amiga Technical Support). 

Supporto marketing 

Per i progetti hardware e software più interessanti, Commodore 
potrà fare da tramite di aiuto e collegamento con editori e pro¬ 
duttori italiani e stranieri, nei limiti imposti da opportunità e di¬ 
sponibilità. 

Altri servizi 

Gli sviluppatori aderenti al Programma di Supporto saranno uf¬ 
ficialmente invitati alle conferenze che periodicamente si ter¬ 
ranno in Italia e all’estero, usufruendo di uno sconto 
particolare. 


Ciò che Commodore si aspetta dagli sviluppatori 

Una volta iscritti come sviluppatori, si è tenuti a rispettare certi 
obblighi in contropartita ai servizi offerti: 

• Tenere al corrente Commodore Italiana dello stato di avan¬ 
zamento dei progetti, con cadenza mensile. 

• In caso si testino versioni preliminari di software e/o har¬ 
dware, informare tempestivamente Commodore Italiana 
dei risultati di questi test, con rapporti scritti dettagliati. 

• Una volta terminato un progetto, inviare tre campioni a 
Commodore Italiana, in modo da tenere un catalogo ag¬ 
giornato dei prodotti disponibili e da poterli diffondere ad 
altre filiali Commodore nel mondo. Naturalmente Commo¬ 
dore Italiana e le altre filiali si impegnano a non diffondere 
i prodotti ad altre società o singoli senza la preventiva au¬ 
torizzazione scritta dello sviluppatore. 

• Impegno a non rivendere Thardware acquistato per lo svi¬ 
luppo nei 12 mesi seguenti l’acquisto, salvo diversi accordi 
scritti. 

• Impegno a rispettare la confidenzialità delle informazioni e 
a non divulgare a terzi le suddette informazioni. 

• Impegno a rispettare le linee direttrici emesse da Commo¬ 
dore per lo sviluppo del software applicativo e dell’har- 
dware aggiuntivo. 

Lo sviluppatore resta comunque unico proprietario e responsa¬ 
bile dei suoi progetti. Commodore non avrà alcun diritto su di 
essi. 

L’organizzazione 

E intenzione di Commodore incoraggiare tutti gli sviluppatori, 
dalla società di sviluppo in grado di commercializzare i suoi 
prodotti all’hobbyista con idee geniali. 

Come si può vedere dal sommario dei servizi offerti da Com¬ 
modore, alcuni di questi sono particolarmente onerosi e saran¬ 
no quindi riservati a gruppi selezionati. 

A questo scopo, sono state create tre categorie di sviluppatori: 
commerciali, certificati e registrati. Commodore deciderà a 
quale categoria un dato sviluppatore appartiene sulla base delle 
informazioni fomite, dei progetti correnti e futuri e della strut¬ 
tura commerciale. 

Lo sviluppatore commerciale è una società che ha già dimo¬ 
strato le capacità di concepire e commercializzare un prodotto, 
si a direttamente che tramite distributori. Potranno essere ac¬ 
cettati in questa categoria anche sviluppatori con progetti in 
applicazioni chiave, di importanza strategica per Commodore. 
I problemi e le richieste poste da questi sviluppatori saranno 
trattati con la massima priorità. 

Lo sviluppatore certificato è una società o un singolo che, pur 
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non commercializzando direttamente un prodotto, lavora co¬ 
munque su progetti interessanti con potenzialità commerciali. 
In questa categoria possono essere compresi università o club o 
gruppi di utenti avanzati (User Groups). Gli sviluppatori certi¬ 
ficati non beneficeranno di supporto telefonico. 

Lo sviluppatore registrato è una società o un singolo interes¬ 
sata/o a progetti su Amiga senza necessariamente avere scopi 
commerciali. Gli sviluppatori registrati non beneficeranno di 
supporto telefonico. 

In seguito all’esame della documentazione relativa alla richie¬ 
sta di partecipazione al Programma di Supporto Sviluppatori 
Amiga, Commodore Italiana valuterà l’opportunità di inserire 
la richiesta stessa nella lista degli sviluppatori "pre-recommen- 
ded", che sarà poi eventualmente ratificata da Commodore In¬ 
ternational, ritornando il numero di iscrizione internazionale. 


Il comunicato sembra sufficientemente chiaro e non dovrebbe 
dare origine a incomprensioni. Comunque ci preme sottolinea¬ 
re un punto che forse non è stato trattato a sufficienza. 

Lo sviluppatore , hardware o software che sia, una volta che ha 
deciso di partecipare all'operazione deve accordarsi con 
Commodore per presentare il proprio progetto. In base alle in¬ 


formazioni ottenute, Commodore International può decidere se 
accettare la domanda ed eventualmente per quale delle tre ca¬ 
tegorie. Nessuno si metta quindi in mente che pagando $500 
possa avere il diritto di appartenere alla categoria degli svi¬ 
luppatori commerciali, deciderà solo Commodore. 

I prezzi praticati ci sembrano corretti, eccezion fatta per quel¬ 
lo dello sviluppatore registrato. In particolare è la figura stes¬ 
so dello sviluppatore registrato che ci lascia perplessi: non ha 
diritto quasi a nulla e quel poco lo deve anche pagare extra. 
La barriera formata dai prezzi da corrispondere a Commodore 
International dovrebbe essere già sufficiente a tenere lontano 
chi non è realmente interessato, ma, se tutto ciò non bastasse, 
ci sarebbe comunque lo scoglio dell'esame da parte di Com¬ 
modore per tenere fuori dalla porta i perditempo e gli scoccia¬ 
tori. 

Inoltre per garantire un lavoro tranquillo agli sviluppatori seri 
occorrerebbe fare piazza pulita una volta per tutte di tutte 
quelle persone che gravitano "nell'ambiente" e in realtà non 
sono altro che pirati. 

II programma di supporto è identico per tutte le nazioni ma, 
per renderlo veramente perfetto per la realtà italiana manche¬ 
rebbe una sola cosa: l’utilizzo di un canale per l’acquisto di 
prodotti hardware o software all' estero. Infatti uno sviluppato- 
re italiano che cosa può sviluppare se non riesce nemmeno ad 
acquistare in Italia un compilatore C? 


Servizi e benefici 



Commerciali 

Certificati 

Registrati 

Abbonamento Amiga Mail 

gratuito 

gratuito 

gratuito 

Abbonamento Amiga Mail Market 

gratuito 

gratuito 

n.d. 

Sconto acquisto Hardware 

(D 

(1) 

n.d. 

Software Public Domain 

gratuito 

gratuito 

a pagam. 

Supporto telefonico 

gratuito 

n.d. 

n.d. 

Accesso BBS 

let./scrit. 

let./scrit. 

lettura 

Sconto acquisto documentazione 

40% 

40% 

n.d. 

Documentazione ulteriore 

gratuita 

a pagam. 

a pagam. 

Documentazione hardware 

gratuita 

a pagam. 

a pagam. 

Sconto parti di ricambio 

(2) 

n.d. 

n.d. 

Beta-Test Software 

gratuito 

n.d. 

n.d. 

Beta-Test Hardware 

gratuito 

n.d. 

n.d. 

BIX amiga.com 

gratuito 

n.d. 

n.d. 

Supporto Marketing 

(3) 

(3) 

n.d. 

Sconto DevCon 

da definire 

da definire 

n.d. 


n.d. = non disponibile 

(1) 25% sul prezzo praticato ai Commodore Point, IVA esclusa, pagamento contrassegno 

(2) 15% sul prezzo di listino, IVA esclusa, pagamento contrassegno 

(3) da valutare a seconda del progetto 


Quote d’iscrizione 


Sviluppatore Commerciale: 
Sviluppatore Certificato: 
Sviluppatore Registrato: 


450 USD per anno, più 50 USD per apertura dossier. 
250 USD per anno, più 25 USD per apertura dossier. 
125 USD per anno, più 25 per apertura dossier. 
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Notizie Amiga 


Hard disk 1.3, dischi RAM multipli e Video Toaster 


di Don Curtis 


Don Curtis è un funzionario di polizia di Denver, in Colorado. 
Negli ultimi due aitili è stato assegnato a! programma di pro¬ 
gettazione e sviluppo e alla progettazione e manutenzione di 
sistema di IO computer AT&T Unix 3B2. Durante il tempo li¬ 
bero Don è assistente Sysop ai CompuServe' s Amiga forum. 

immagazzinare l’FFS nello stesso hard disk in un formato cari¬ 
cabile. Questo significa che, seguito il corretto procedimento, 
si può effettuare l’autoboot di una partizione FFS. Le periferi¬ 
che della Great Valley lo possono fare mediante la loro Auto- 
Boot ROM, come pure le HardFrame della MicroBotics. In un 
prossimo futuro lo farà anche la Commodore. 

Recentemente ho raccolto molte piccole notizie dalle reti e ho 
pensato di approfittare di questo numero per divulgarne il più 
possibile. Ho provato a usare tutti gli elementi che ho potuto, 
ma non ho tutte le combinazioni possibili di hardware e soft¬ 
ware, per cui non posso garantire sulla loro efficacia. Posso so¬ 
lo dire che le informazioni ottenute derivano da fonti 
attendibili, e dove possibile, sono state verificate da altre per¬ 
sone che le hanno provate. Tuttavia, come sempre, prima di ef¬ 
fettuare un nuovo esperimento assicuratevi di aver una copia di 
backup dei vostri dati; cosi facendo, nel caso in cui resperi¬ 
mento non funzionasse, non avrete perso nulFaltro che un po’ 
di tempo. 

Coloro che hanno accesso ai file include della nuova versione 

1.3 troveranno le informazioni in devices/hardblocks.h e re- 
sources/filesysres.h. Tali informazioni, estremamente funzio¬ 
nali, sono però troppo complicate per poter essere riportate qui. 

Vi è inoltre un enorme vantaggio: è possibile aggiornare il file- 
system senza sostituire la ROM. 

Problemi con Tinterfaccia SCSI? 

Si sono manifestati dei problemi nel funzionamento di un drive 
e/o una periferica SCSI? Pare che alcuni costruttori di device 
SCSI non curino correttamente le linee 20,22,24,28,30 e 34. 

Ri-validazione dell’Hard Disk 

Alcune di tali linee, che non dovrebbero essere collegate, ven¬ 
gono messe a 5 volt, mentre altre vengono collegate a terra. 

Vi è capitato, cominciando a usare il nuovo Fast Filing System 
(FFS), di scoprire improvvisamente che avviene una rivalida- 
zione durante un LoadWB dallo startup script? 

Qualora un device sia posto a 5 volt e la corrispondente linea 
di un altro device sia a terra, collegando questi due allo stesso 
bus SCSI si manifesteranno ovvi problemi. 

Questo succede se avete assegnato T: alla partizione dell'Hard 
Disk sul vostro Old File System (OFS). Ed ecco come: FOFS 
ha un bug che provoca in ogni caso un’inibizione, anche se 
avete attualmente un file aperto per la scrittura. Quando lancia¬ 
te con il comando execute un file che avete scritto, "execute" 
scrive in T:; quando date il comando LoadWB, il WorkBench 
controlla tutta la lista di device per verificare se si tratta o me¬ 
no di un drive. L’execute ha aperto la directory OFS T: per la 
scrittura e il WorkBench la ha appena inibita! 

La soluzione è semplice: è sufficiente non collegare queste li¬ 
nee al vostro cavo SCSI. 

Scheda di autoboot per l’Amiga 2090 

Siete infastiditi perché FA2090 del vostro Amiga non riesce ad 
autoavviarsi anche se avete installato le ROM. versione 1.3, 
del sistema operativo nel vostro A500 o A2000? La Commo¬ 
dore sta venendo in vostro aiuto, non dovrete sostituire la vo¬ 
stra scheda A2090 con una A2090A; immetterà invece sul 

In questo caso, che cosa fa quindi il sistema? Rivalida la parti¬ 
zione OFS per definire la bit-map. Ciò è molto semplice e si 
ottiene assegnando T: a RAM:. In questo modo il problema è 
risolto. 

mercato una scheda separata per l'autoboot. 

La scheda sarà composta da una ROM di autoboot che cerche¬ 
rà FA2090 e, dopo averlo abilitato, lo avvierà dalla stessa. La 
scheda dovrà essere inserita in uno slot Amiga. 

Autoboot di una partizione FFS. 

Non vi è ancora nessuna notizia relativa al costo e alla disponi- 

La Commodore fornisce attualmente un metodo standard per 

bilità di una tale scheda, che si chiama A2090B. in ogni caso 
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l'Amiga dovrà avere la versione 1.3 del sistema operativo su 
ROM per poter funzionare. 

Anche la Michigan Software è in procinto di immettere sul 
mercato una scheda simile. Tale scheda sarà dotata di una 
RAM servita da una batteria tampone e utilizzerà una RAM 
statica. Avrà una capacità di memoria di 64K espandibile sino 
a 256K e utilizzerà 8 chip di RAM statica a 32 bit. L'Hardware 
non permetterà la scrittura sul disco virtuale così da impedire 
la perdita dei dati. Sarà in grado di abilitare tutte le partizioni e 
potrà autoavviarsi da un drive FFS. Avrà anche una priorità di 
avvio definibile dall'utente nel caso si abbia nel sistema più di 
un device in autoboot. 

Infine avrà Fautoboot selezionabile tramite un interruttore. In 
questo modo, se state ancora usando la ROM 1.2, il sistema 
non va in crash. Un device di autoboot usato con la versione 
1.2 manda in crash il sistema, ecco perché in tutti i device di 
autoboot attuali (come FA2090A) le ROM non vengono instal¬ 
late alla spedizione. Anche in questo caso non si ha alcuna in¬ 
formazione su quando sarà disponibile o quanto potrà costare, 
si sa solo che è in via di sperimentazione. 

Avvertenze per il drive SCSI della Seagate 

Se avete una scheda A2090A, avrete letto le avvertenze riguar¬ 
do Fuso dei drive SCSI della SeaGate (quelli che nel nome del 
modello hanno il suffisso N) come drive di autoboot. 

Prima di tutto il problema insorge solo in un’avvio a freddo e 
non in una partenza a caldo. La ragione è che i drive della Sea¬ 
gate hanno un valore di intervallo più lungo per accendersi ed 
eseguire l’auto test rispetto alle schede. Se avete drive SCSI 
della Seagate e una scheda A2090A e volete usarli in autoboot, 
vi sono alcune accorgimenti da seguire. 

La prima cosa da fare è avviare i drive Seagate separatamente 
e accenderli 15 secondi circa prima di accendere l’Amiga. La 
seconda è di permettere che fallisca il primo avvio a freddo e 
poi resettare l’Amiga usando i tasti Ctl-Amiga-Amiga. L'ulti¬ 
ma cosa che vi resta da fare è aspettare che la Commodore esca 
con i nuovi drive di sua produzione sui quali stanno lavorando 
e che risolveranno anche questo problema. 

L’uso dell’FFS in una partizione di disco MS-DOS 

Volete usare l’FFS sulla partizione dell’Amiga di un hard disk 
MS-DOS con la Bridge-Board? Si. potete usare l'FFS con JHO: 
(oppure JH1:. JH2:, ecc.). 

Usate la formattazione normale a basso livello e partizione del 
drive utilizzando FDISK e ADISK. poi, invece di usare i co¬ 
mandi DJMount e DJFormat per eseguire il mount e la format¬ 
tazione del drive, date i comandi normali dell’AmigaDOS 
"mount" e "format". Poi create un elemento della mountlist per 
ogni partizione JHx: che avete creato. Il device si chiamerà 
jdisk.device (e quel file deve essere in DEVS: oppure nella li¬ 
nea "Devices" deve essere descritto il giusto percorso). JHO: 
corrisponde all’unità 0, JH1 : all’unità 1 e così via. Usate i ci¬ 
lindri di inizio e fine appropriati quando li definite con FDISK 


e ADISK. 

La stessa cosa per quanto riguarda il numero delle testine, delle 
superfici, e via dicendo. Le altre informazioni sono le stesse 
che si usano in ogni Fast File System drive (Buffer, FileSy- 
stem, GlobVec, DosType, ecc.). Prendete come esempio la 
mountlist (con le modifiche dovute) che si trova a pagina A-3 
del manuale dell’ 1.3. 

Una volta che siete sicuri di aver fatto tutto secondo le regole 
potete eseguire il mount e formattare il drive con i comandi 
standard "mount" e "format" dell’AmigaDOS. Noterete ancora 
un rallentamento causato dal fatto che i dati passano attraverso 
l’interfaccia Janus, ma avrete un accesso ai dati più veloce e un 
5% in più di spazio sul drive. 

L’uso di FFS con il drive Xebec 9720HD 

Avete un drive Xebec 9720HD e volete usare il Fast File Sy¬ 
stem? Io ho anche trovato un modo per rendere possibile que¬ 
sta operazione. Prima di tutto DOVETE avere la versione 3.0 
dello "scsi.device" della Xebec. Potete determinare quale ver¬ 
sione avete andando nella directory DEVS: del vostro disco di 
boot e dando il comando: 

type scsi.device opt h 

Nelle prime linee che appariranno sullo scherno ne troverete 
una che vi dirà il numero di versione. Se non avete la versione 
3.0 NON cercate di usare il drive con un FFS, PERDERESTE 
dei dati. 

Un altro avvertimento da dare, è che non tutti quelli che hanno 
cercato di fare questo hanno avuto successo. Molti ci sono riu¬ 
sciti ma alcuni hanno detto che sembrava che tutto funzionasse 
alla perfezione mentre dopo qualche giorno hanno riscontrato 
degli errori. Ciò è probabilmente legato a un valore sbagliato 
della linea MaxTransfer nella mountlist, ma non si è ancora si¬ 
curi. Per questo motivo fate copie frequenti dei vostri dati nel 
caso in cui vi siano dei problemi. Più avanti parleremo ancora 
del MaxTransfer. 

Per preparare lo Xebec come drive FFS. non usate il suo co¬ 
mando scsimount e il suo file hdparms. Dovrete trattare lo Xe¬ 
bec esattamente come qualsiasi altro hard disk e creare un 
elemento nel file mountlist per lui usando il tipico formato 
FFS. Il Device dovrà essere "scsi.device" e il numero di unità 
dovrà essere 1. Se avete smarrito la vostra documentazione, il 
9720 ha 4 testine, 612 cilindri (numerati da 0 a 611) e 17 setto¬ 
ri per traccia. Assicuratevi ancora una volta di usare gli appro¬ 
priati FileSystem, DosType e GlobVec. Come detto in 
precedenza, prendete come esempio la mountlist che si trova a 
pagina A-3 del manuale di istruzioni. 

L’uso corretto di MaxTransfer 

Usate nella maniera giusta le linee della mountlist di MaxTran¬ 
sfer? MaxTransfer è un parametro di limite, non un parametro 
di accellerazione! 
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Alcune schede di controllo dei drive possono trasferire solo 
una limitata quantità di dati per volta, se la vostra richiesta è 
maggiore la scheda di controllo andrà in sovraccarico e rovine¬ 
rà i vostri dati. La soluzione a questo problema è il parametro 
MaxTransfer. 

MaxTransfer limita la quantità di dati che possono essere letti 
o scritti sul drive in una singola richiesta fino al numero di byte 
specificati. Nella versione 1.3 del manuale c'è scritto che Max- 
Transfer deve essere specificato in blocchi, ma ciò non è cor¬ 
retto: deve essere specificato in byte. 

Un modo semplice per verificare se c'è bisogno di un valore 
MaxTransfer nella mountlist è di creare sull'hard disk due di¬ 
rectory: testi e test2. Per prima cosa copiate alcuni grossi pro¬ 
grammi (100K di dimensioni o più è sufficiente: maggiore è la 
dimensione del file, migliore sarà il test) nella directory testi. 
Quindi provate a lanciare i programmi. Se tutto funziona bene 
passate alla prossima fase. Se non funziona aggiungete il para¬ 
metro MaxTransfer alla mountlist. Cominciate con 65536, 
riavviate il computer e provate di nuovo. Se tutto funziona a 
questo punto passate alla prossima fase, altrimenti dimezzate il 
valore del parametro MaxTransfer, riavviate e provate ancora. 

Superata questa fase, copiate l’intero contenuto della directory 
testi nella directory test2 usando l’opzione ALL del comando 
Copy (Copy DH0:testl to DH():test2 ALL). Ora provate a lan¬ 
ciare di nuovo i programmi. Se tutto funziona siete a cavallo! 
Altrimenti tornate alla procedura precedente per aggiungere il 
paramentro MaxTransfer. riavviate e riprovate ancora. 

L'hard disk di serie 

La Commodore ha annunciato che tutti i nuovi modelli Amiga 
saranno venduti con l’hard disk di serie. Ma non solo, l’hard 
disk avrà il sistema operativo già installato. 

Pochi giorni dopo ha annunciato che uscirà l'Amiga 2000HD; 
un’Amiga 2000 con la scheda di controllo A2090A e l'hard 
disk da 40 MB con tempo di accesso di 28 ms, a 2999 dollari. 

Hanno anche annunciato l’Amiga 2500: un’Amiga 2000 con la 
scheda A2090A. un hard disk da 40 MB. 28 ms, e la scheda 
A2620 con il microprocessore 68020 e coprocessore con 2 MB 
(espandibile a 4 MB) di RAM a 32 bit reali per 4699 dollari e 
sarà in grado di ospitare l’ambiente UNIX. 

Altre notizie sulla Versione 1.3 

Si presume che tutti sappiate che la versione 1.3 del sistema 
operativo Amiga è disponibile già da tempo e sono sorte alcu¬ 
ne particolarità e/o correzioni interessanti. 

Come abbiamo detto in precedenza, MaxTransfer è definito 
come il numero massimo di blocchi trasferiti. In effetti limita 
invece il numero di byte trasferiti. Mentre il comando "format" 
mostra le opzioni FFS e NOFFS. di fatto legge anche le infor¬ 
mazioni in una mountlist, se possibile, e selezionerà corretta- 
mente il giusto metodo di formattazione (FFS o OFS) con o 
senza le opzioni. Andy Finkel dice che nella versione futura 


eliminerà quelle opzioni dal "format". 

Se avete un set di chip da 1 MB (come alcuni programmatori) 
e usate SetPatch, il manuale dà l’informazione errata per quan¬ 
to riguarda l’opzione R poiché è sensibile rispetto alle lettere 
maiuscole o minuscole e DEVE essere minuscola. 

Drive RAM multipli 


Se usate RAD: e FFS, vi sono dei problemi di ripristino del si¬ 
stema. Questo si può risolvere aggiungendo la linea 
"Mount=l" alla vostra mountlist. Facendo ciò il sistema riesce 
a eseguire il recupero come dovrebbe. Un utente ha dichiarato 
che il recupero è avvenuto anche dopo numerosi riavvii inter¬ 
medi, senza il rnount del drive, sul riavvio finale; il sistema ha 
eseguito il mount e ha effettuato il ripristino totale. 

E anche possibile avere RAD:s multiple con l'uso di un editor 
di settore o di file per effettuare alcune modifiche su "ramdri- 
ve. device". 

Prima copiate ramdrive.device in ramdriv 1 .device (il nome del 
file DEVE avere lo stesso numero di caratteri!), poi editate il 
file usando un editor di file o settore (come NewZap). Nel byte 
171 esadecimale troverete il carattere ASCII "e", cambiatelo in 
un 1. Se riuscite a vedere il file significa che avete sostituito la 
stringa "ramdrive.device" con la stringa "ramdriv 1.device". 

Ora andate al byte 5A1 esadecimale (dall’inizio del file) e 
cambiate il carattere ASCII 0 in 1. In questo modo avete cam¬ 
biato la stringa RAMB0 in RAMB1. A questo punto duplicate 
la linea della mountlist di RAD: come RADI: e cambiate la li¬ 
nea "Device=” in ramdriv 1.device. 

Eseguite il mount di RADI:, avrete così un secondo drive 
RAM ripristinabile. Potete ripetere l’operazione con RAD2: e 
molti altri, e la memoria ve lo permetterà finché creerete per 
ognuno un driver e una mountlist separati con i cambiamenti 
necessari nel driver e nella mountlist. 

Incompatibilità di software 

Se nel vostro Amiga avete la ROM versione 1.3 alcuni pro¬ 
grammi non funzioneranno. Anche in questo caso alcuni pro¬ 
grammatori si sono riferiti alle entry codificate nell’hardware 
della ROM versione 1.2, che sono cambiate con la 1.3. Vorrei 
tanto che gli autori di programmi imparassero che nell’Amiga 
esiste solo UN indirizzo assoluto dal quale si può dipendere, 
cioè AbsExecBase. Almeno che usino quello per trovare i pun¬ 
ti di accesso alla ROM. 

Spero che le informazioni che vi ho dato vi siano utili. Come 
potete vedere vi sono metodi giusti e sbagliati per fare le cose, 
speriamo che scelgano tutti la metodologia corretta in modo 
che i cambiamenti apportati all'hardware o al sistema operati¬ 
vo non provochino più l’arresto dei programmi! 
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Il WorkBench 1A e oltre 


di Larry Phillips 

Larry Phillips è un hacker hardware e software di Amiga di 
Vancouver, British Columbia, ed è SysOp (System Operatol i al 
"CompuServe ' s AmigaForum ", 

Come si poteva ben prevedere la versione 1.3 della Commodo¬ 
re ha fomentato varie discussioni sull’1.4, e gran parte di que¬ 
ste osservazioni si focalizzano su uno dei principali obiettivi 
dell’1.4: il miglioramento dell’ambiente WorkBench. L'Amiga 
è una macchina basata sulle scelte per qualsiasi cosa, dai colori 
e puntatori ad apparecchiature esterne hardware e, persino, per 
la scelta dell'interfaccia utente: il CLI o il WorkBench. 

Sfortunatamente solo una delle scelte dell’interfaccia utente 
può essere usata per tutte le cose, mentre l’altra ha un uso limi¬ 
tato. Il CLI può essere usato per qualsiasi cosa, infatti il Wor¬ 
kBench non ha mai bisogno di essere caricato per poter usare a 
pieno la potenza della macchina. Il WorkBench, tuttavia, non è 
assolutamente adatto se comparato al CLI per qualsiasi cosa 
che non sia lanciare applicazioni e le più rudimentali routine di 
"mantenimento". 

Questo stato di cose ha causato la scrittura di numerosi stru¬ 
menti che cercano di dare maggior potere al WorkBench. Han- 
dyWB, Browser, IconX e altri, tutti tentano di superare i difetti 
dell’ambiente WorkBench. Fanno un lavoro discreto nel cam¬ 
po per il quale sono stati creati, ma i problemi del WorkBench 
sono molto più seri. Sfortunatamente le soluzioni portate avanti 
per un miglioramento generale del WorkBench non sempre ri¬ 
solvono veramente il problema, ma lo sfiorano appena. 

Il WorkBench, come è adesso, è "a filo unico". Non deve esse¬ 
re confuso con il Single-Tasking, significa semplicemente che 
si deve finire una certa operazione che si sta facendo prima di 
poterne iniziare un’altra. 

Non siete mai stati assaliti dalla noia aspettando che qualcosa 
si caricasse mentre osservavate il puntatore a forma di fumetto 
dormiente? Cliccate su una finestra, si apre immediatamente e 
il disco inizia a cercare le icone. Ecco che appare la prima: il 
programma che volete. Giunge la frustazione perché il disco 
deve ancora trovare cinque o sei icone e visualizzarle prima 
che voi possiate veramente cliccare su quella che volete. Male¬ 
dite il WorkBench. "Questa è una macchina Multi-Tasking" di¬ 


te, "perché non posso continuare a cliccare sulle cose?" 

Vorrei che la risposta fosse semplice. Dipende tutto dal fatto 
che il WorkBench non sa veramente quello che volete fare. Gli 
state dicendo di fermare quello che sta facendo e di cominciare 
l’operazione seguente? Forse volete che inizi l’operazione se¬ 
guente mentre continua quella precedente? Forse quello che in¬ 
tendete veramente è "inizia la prossima operazione quando 
questa è finita". 

Se si tratta del primo caso potete essere sicuri che ci sarebbero 
molte volte in cui avreste veramente bisogno di vedere il resto 
delle icone, le quali naturalmente non apparirebbero mai per¬ 
ché il "raccoglitore di icone" è stato fermato, e naturalmente 
"abortire" un programma per caricarne un altro non è quello 
che volete fare, quindi bisognerà trattare diverse operazioni in 
diversi modi. 

La seconda scelta, iniziare la seconda operazione mentre la pri¬ 
ma sta continuando, è forse la cosa peggiore. E sarebbe parti¬ 
colarmente noioso per coloro che usano solo i floppy perché le 
due operazioni sarebbero in competizione per l’uso del disco. 

Se non avete mai caricato due programmi contemporaneamen¬ 
te da un floppy provate a farlo utilizzando due diversi CLI. Li¬ 
tigheranno per posizionare la testina del drive e anche se alla 
fine riusciranno a portare a termine le loro operazioni, sarà un 
processo lungo e rumoroso. Tutte le lamentele sulla lentezza 
dell’accesso alle directory e ai programmi da floppy e il per¬ 
mettere l’accesso contemporaneo al disco da WorkBench fan¬ 
no più male che bene all’Amiga. 

L'ultima scelta, cioè il permettervi di cliccare prima che l’ope¬ 
razione in corso sia terminata è relativamente innocuo. La 
maggior parte delle volte funziona sebbene in realtà non accel- 
leri le operazioni, ma fa in modo che l'utente abbia maggior 
confidenza con l’ambiente. 

Un’altra possibilità che nessuno ha ancora menzionato è che 
l’operazione in corso venga sospesa mentre la successiva inco¬ 
mincia. e continui quando la successiva è terminata. Questa so¬ 
luzione ha i suoi problemi, specialmente su una macchina a 
512K, a meno che non si faccia attenzione a evitare l’esauri- 


m 































0 


Transactor per AMIGA 


■ n 


mento della memoria causato da una moltitudine di task in so¬ 
speso mentre ne lanciate sempre di nuovi. 

Un altro argomento largamente discusso è quello della "visibi¬ 
lità" dei file. Un CLI vi permette di vedere tutti i file di una di¬ 
rectory, il che è una delle principali ragioni per cui il CLI è più 
adatto al pieno controllo della macchina. Il WorkBench, inve¬ 
ce, vi permette di vedere solo delle icone, e questo porta al rag¬ 
giungimento di scopi ben più lontani, sia nell’utilità del Work¬ 
Bench che nel modo dell'utente di avvicinarsi alla macchina. 

Le icone, naturalmente, possono essere viste come rappresenta¬ 
zioni di oggetti. Cliccate (o cliccate due volte) su un oggetto, e 
aspettate che accada qualche cosa, e quello che accade dipende 
esattamente dal tipo di oggetto sul quale state cliccando. Que¬ 
sto va bene per cose come lanciare programmi o aprire cassetti, 
ma spesso vi sono molte operazioni che volete probabilmente 
eseguire utilizzando quell’oggetto e siete ostacolati dalla rap¬ 
presentazione a icone. Poiché rappresenta veramente un ogget¬ 
to che fa una particolare cosa, ci deve essere un altro metodo, 
oltre al semplice cliccare sulla icona, per indicare alla macchi¬ 
na che volete fare qualche cosa di diverso dalla normale opera¬ 
zione. In parte questo è stato fatto nella selezione dei menu su 
WorkBench per operazioni come duplicare (Duplicate), cam¬ 
biare il nome (Renarne), avere informazioni (Info), cancellare 
(Discard), ecc. 

Il problema principale in questo caso è che l’icona, mentre rap¬ 
presenta un oggetto, non necessariamente rappresenta il giusto 
tipo di oggetto per un altro tipo di operazione. Un buon esem¬ 
pio può essere il copiare un programma da un disco a un altro. 
Quando clicchiamo su un’icona e tenendo schiacciato il tasto- 
dei mouse la spostiamo in un altro disco o cassetto, facciamo 
più che non solo copiare l’icona stessa: stiamo copiando l'ico¬ 
na e il programma con lo stesso nome. Sfortunatamente molti 
programmi non si trovano in un solo file e forse neppure in un 
solo cassetto. In questo caso, per l'operazione di copiatura, 
l’oggetto è diverso. Quello che vogliamo fare effettivamente è 
copiare l’intero programma inclusi tutti i file di supporto. 

La soluzione più comune portata avanti per risolvere questo 
problema è che abbiamo bisogno di vedere tutti i file su un da¬ 
to disco usando il WorkBench. Alcuni dicono che dovremmo 
vedere le icone di quei file che le hanno, e il testo per quei file 
che non le hanno, mentre altri sostengono che l’immagine di 
default per le icone dovrebbe inserirsi nei file che non hanno 
una icona specifica. A prima vista questa soluzione sembra 
semplice e diretta, risolvendo tutti i casi, ma è più complessa. 

La complessità deriva dalla filosofia della stessa interfaccia 
utente. Il WorkBench mira a rendere le cose più facili per l’u¬ 
tente e in particolare per i nuovi utenti del computer. Si suppo¬ 
ne che elimini il timore nei riguardi del computer, nascon¬ 
dendo i dettagli cruenti e permettendo all’utente di vedere le 
cose in termini di lavori da fare, piuttosto che i dettagli di come 
gli stessi lavori devono essere organizzati perché funzionino. 

È troppo semplice, per un utente Amiga esperto, dire che il 
WorkBench dovrebbe permettere di vedere tutti i file senza 
considerare gli effetti sul principiante di una solida barriera di 


icone o uno schermo pieno di nomi di file, magari che escono 
fuori dallo schermo richiedendo delle barre di scorrimento o al¬ 
tri mezzi per vederli tutti. In primo luogo questo minimizza 
l’utilità dell’ambiente WorkBench. Immaginatevi un utente al¬ 
le prime armi che vede font, driver di device, librerie, e così 
via, che clicca su queste e si domanda perché non abbiano fatto 
qualche cosa di utile. C’è veramente differenza tra vedere tutti 
i files sul WorkBench e usare un CLI? 

Penso che sicuramente dobbiamo essere in grado di fare un uso 
maggiore del WorkBench e che dobbiamo essere in grado di 
usarlo per vedere tutti i file, ma che questi bisogni non devono 
mai perdere di vista la filosofia sottostante dell’interfaccia 
mouse/icona. Vi sono molti modi per farlo, e alcuni di questi 
richiederebbero una completa rielaborazione del WorkBench, 
mentre altri richiederebbero il mantenimento di vecchi metodi 
insieme a nuovi metodi, per fare in modo che i vecchi pro¬ 
grammi funzionino in maniera appropriata. 

Il WorkBench dovrebbe probabilmente abbandonare gran parte 
delle caratteristiche attuali, mantenendo solo le icone, che sono 
molto utili in termini di lavori da effettuare, e il tipo di natura 
del WorkBench orientata verso l'applicazione. 

Ulteriori opzioni potrebbero descrivere meglio la struttura sot¬ 
tostante dei file di un disco allo scopo di copiare tutte le appli¬ 
cazioni su un altro disco oppure per manipolare tutti i file che 
appartengono a un’applicazione. Un’altra opzione potrebbe da¬ 
re più file, magari anche tutti, per offrire all’utente un controllo 
definitivo simile al CLI sulla macchina. 

I proprietari di Amiga hanno proposto molte buone idee come: 
menù definibili dall'utente, possibilità di modificare lo sfondo, 
possibilità di scegliere il lato dello schermo su cui posizionare 
le icone dei dischi, mantenere il giusto rapporto nella raffigura¬ 
zione delle icone in schermi interlacciati, creare diversi metodi 
per la selezione estesa, e altre ancora: molte di queste, inoltre, 
non hanno alcun effetto negativo sia sul nuovo utente che su 
quello esperto. 

Alcune di queste idee possono essere considerate più che un 
fatto di sola estetica, e hanno la loro importanza. Tuttavia è an¬ 
cora più importante che tutti gli utenti siano a proprio agio con 
l’interfaccia utente che più si addice a loro; il solo modo per 
ottenere questo è rendere gli ambienti CLI e WorkBench 
ugualmente potenti. Solamente permettendo delle scelte che 
non portino a compromessi l’Amiga potrà diventare un compu¬ 
ter dal fascino irresistibile. 

Per anni il Mac ha subito i tentativi della Apple di restringere 
l’attività della macchina al solo uso mouse/icona, e le macchi¬ 
ne MS-DOS non avevano altro che la possibilità dell’interfac¬ 
cia con la linea di comando. In seguito altre persone hanno 
fatto ogni sforzo per risolvere i difetti dell’uno e dell’altro tipo 
di interfaccia utente. L’Amiga è la prima macchina che ha cer¬ 
cato di offrire il meglio di entrambi gli ambienti pronti all’uso, 
e lo ha fatto in maniera egregia. Certo non è tutto perfetto, spe¬ 
cialmente in ambiente WorkBench, e potrebbe essere migliora¬ 
to considerevolmente, in modo che la filosofia di base di ogni 
interfaccia utente sia sempre tenuta in considerazione. 
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I Transputer su Amiga 


Come e perché 


di Howard Oakley 

II Dott. Oakley è ricercatore in fisiologia presso la Rovai Na- 
vy, specializzato in sopravvivenza umana. La sua attività com¬ 
prende anche la programmazione dei Transputer, di Amiga, 
Macintosh e PC, in modo particolare nelle applicazioni di cal¬ 
colo. I suoi prodotti commerciali comprendono un programma 
per la progettazione delle vele navali. Attualmente sta lavoran¬ 
do a Mercury, un sistema operativo per Transputer. È uno dei 
fondatori del Transputer Users’ Group. 

Negli ultimi anni si è sentito parlare spesso di Transputer fra 
gli entusiasti di computer, anche se la maggior parte delle per¬ 
sone normali risulta piuttosto all’oscuro su questo argomento. 
Durante l'ultimo anno, in particolare, la disponibilità crescente 
di queste macchine, lo sviluppo dell’ATW (Atari Transputer 
Workstation) e le dimostrazioni tenute dalla Commodore di 
una scheda Transputer per Amiga, hanno creato una quantità di 
esperti improvvisati, di entusiasti che non vedono l’ora di po¬ 
terne mettere uno nel proprio computer e di persone che sono 
convinte che tutti i loro problemi saranno risolti. 

Sebbene i Transputer possano sicuramente offrire benefici so¬ 
stanziali ai loro utilizzatori, se tutto fosse così semplice, il 
mondo ne sarebbe già pieno (sicuramente verrebbero prodotti 
in un buon numero di paesi dell’estremo est). Il progetto del- 
l’Atari, infatti, è ormai vecchio di un anno, così come la scheda 
della Commodore del resto, sebbene nessuna delle due sia an¬ 
cora liberamente disponibile presso i rivenditori. Chiaramente, 
sebbene i Transputer si prestino a risolvere certi problemi, ne 
devono anche creare qualcuno. 

Che cos’è un Transputer 

Nonostante la discussione sulla filosofia di progettazione del 
68000 possa risultare di relativo interesse al programmatore di 
Amiga, quella del Transputer è essenziale per chiunque voglia 
considerare cosa farsene di uno di questi. Anziché espandere e 
costruire su un progetto già presente, la Inmos partì con un fo¬ 
glio bianco e implementò una forma di parallelismo particolar¬ 
mente elegante e semplice. Questo sviluppo è stato descritto da 
C. A. R. Hoare in vari articoli e successivamente in un libro in¬ 
titolato "Communicating Sequential Processes" e forma la filo¬ 
sofia di progetto sia per i chip Transputer, sia per YOccam, il 
loro linguaggio di programmazione preferito. 


Il Transputer non è, come spesso si legge, un chip RISC. Pos¬ 
siede invece un ingegnoso set di istruzioni che consiste di codi¬ 
ci lunghi un byte per il 70% di quelle usate più fre¬ 
quentemente, che possono gradualmente diventare otto byte 
per istruzioni usate molto di rado. 

Questo porta a un altro malinteso molto comune, riguardante i 
test di velocità (benchmark). 

Siccome i codici delle istruzioni (opcode) di un Transputer non 
sono a lunghezza fissa, la velocità reale del chip è variabile. 
Un Transputer con clock di 20Mhz raggiungerà la velocità più 
alta di 10 milioni di istruzioni per secondo (MIPS) solo usando 
istruzioni lunghe un singolo byte. Metteteci qualche complessa 
elaborazione in floating point o qualche altra astrusa operazio¬ 
ne e la velocità calerà molto presto. 

Anche il set di istruzioni è abbastanza bizzarro sotto alcuni 
punti di vista. Il Transputer vede una serie di processi, ognuno 
dei quali possiede la propria memoria dati (zona di lavoro che 
può essere alterata ma non legalmente condivisa) e il proprio 
codice. E molto semplice preparare questi processi, in quanto è 
veramente solo questione di allocare uno spazio di lavoro e di 
metterci dentro il codice. Il processore pensa poi indipendente¬ 
mente a passare il controllo fra i vari processi secondo il siste¬ 
ma chiamato round-robin. Per prima cosa tenta di eseguire il 
processo che si trova nella posizione più alta della lista dei pro¬ 
cessi pronti (ready). Se l’operazione riesce, il controllo rimane 
a quel processo fino a quando un certo tempo (fisso) non è pas¬ 
sato, anche se il processore controlla il passare del tempo solo 
durante l’esecuzione di un piccolo numero di istruzioni fra le 
quali LOOP e le istruzioni per le comunicazioni. Successiva¬ 
mente il controllo viene passato al prossimo processo nella li¬ 
sta e così via. 

Questo è complicato dall’esistenza di processi con priorità alta, 
che sono stati introdotti per permettere la programmazione di 
routine di tipo interrupt o trap. Un processo con priorità alta 
non viene interrotto dopo un intervallo di tempo, ma viene ese¬ 
guito fino a quando non si deve fermare perché termina o per¬ 
ché deve comunicare. 

Le comunicazioni avvengono attraverso dei canali, costituiti da 
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memoria condivisa ed efficacemente delimitata. Un processo 
spedisce un messaggio mettendolo nella zona del canale, men¬ 
tre il ricevente lo legge prendendolo dalla locazione alla quale 
era stato depositato. Uno dei due può venire fermato in attesa 
che l’altro sia pronto a terminare le procedure di scambio del 
messaggio, quindi i canali possono essere utilizzati per sincro¬ 
nizzare più processi fra di loro, così come possono essere uti¬ 
lizzati per spostare dati da un processo all'altro, da cui deriva 
la denominazione communicating sequential processes (pro¬ 
cessi sequenziali intercomunicanti). 

I quattro Transputer 

I Transputer sono disponibili attualmente in quattro tipi diversi. 

II meno pregiato è il T212, 16 bit, molto economico e poten¬ 
zialmente utile nel trattamento di array molto grandi o nel con¬ 
trollo di periferiche. Da questo è stato derivato TM212, 
progettato per il controllo dellT/O, in modo particolare per gli 
hard disk ad alta velocità e per altri supporti di memorizzazio¬ 
ne. 

II T414 è stato il primo Transputer a 32 bit. Possiede 2K di me¬ 
moria interna e quattro canali di comunicazione, ma non un co- 
processore (e sottrae cicli al processore durante le operazioni di 
comunicazione). 

Il T800 è attualmente il modello di punta della serie. Possiede 
4K di memoria interna, quattro canali di comunicazione (che 
non sottraggono cicli macchina al processore) e un coprocesso- 
re matematico molto veloce, il tutto in un solo chip. La Inmos 
sta già producendo limitati quantitativi di prova di nuove ver¬ 
sioni più sofisticate della famiglia Transputer. 

Le dimensioni e le maniere in cui viene utilizzata la memoria 
interna sono spesso critiche per le prestazioni di questi proces¬ 
sori, in quanto sono essenzialmente privi di registri. In ogni ca¬ 
so, si hanno sempre a disposizione fino a 4K da riempire di 
codice e/o dati, i quali godono di tempi di accesso paragonabili 
a quelli dei registri di un chip convenzionale. Nei lavori di cal¬ 
colo intensivo, per esempio, nei quali possiamo trovare poche 
variabili ma grosse porzioni di codice da eseguire, potrebbe ri¬ 
sultare molto conveniente mettere le routine più critiche nella 
RAM interna. 

Fino a un anno fa, la maggior parte degli utenti di Transputer 
lavoravano con il T414, poiché il T800 era disponibile solo in 
quantità dimostrative (e non era ancora privo di bug). 

La transizione all 'utilizzo del T800 non è stata facile, in quanto 
quest'ultimo prima di tutto è più costoso e in secondo luogo 
possiede un set di istruzioni diverso da quello del precedente 
T414. Non è nemmeno facile generare codice che possa girare 
indifferentemente su entrambi i modelli, dal momento che il 
T414 possiede alcune istruzioni non disponibili sul T800. Fino 
a quando il prezzo dei T800 non scenderà tanto da fare sparire 
i T414, ci saranno sempre questi problemi di compatibilità e la 
Inmos appare determinata a introdurre nuovi cambiamenti nei 
futuri chip. 

Probabilmente l'unica caratteristica veramente innovativa di 


questi chip consiste nei canali di comunicazione ad alta veloci¬ 
tà, che permettono di collegare un gran numero di CPU. La ve¬ 
ra velocità che si ottiene da questi canali varia in modo 
considerevole. I T800 dovrebbero gestire 20 megabit al secon¬ 
do in modo unidirezionale e poco meno durante trasmissioni 
bidirezionali. Queste velocità dovrebbero aumentare ulterior¬ 
mente nei modelli più recenti. Ma sareste molto fortunati a ot¬ 
tenere prestazioni, anche solamente paragonabili a quelle di 
questo tipo, durante il passaggio di dati da e per un computer 
host (il computer che ospita la scheda Transputer), anche se si 
trattasse del velocissimo 68030. L’adattatore usato nel collega¬ 
mento e la lentezza intrinseca dell’nost ne avranno presto ra¬ 
gione.- 

Sono state proposte fondamentalmente due soluzioni per que¬ 
sto problema. La più semplice dal punto di vista software con¬ 
siste nell’utilizzo di hardware più intelligente come la RAM a 
due porte, alla quale possono accedere normalmente sia il 
Transputer che il processore host. La più stimolante dal punto 
di vista software si basa invece sull’uso dell'accesso diretto al¬ 
la memoria (DMA Direct Memory Access), come avviene nel¬ 
l’ultima scheda Transputer per PC prodotta dalla MicroWay e 
nel prototipo della Commodore. 

Ma. probabilmente, la maggiore delusione di coloro che inve¬ 
stono denaro in costose schede Transputer e nei relativi compi¬ 
latori arriva quando scoprono che i processi sequenziali 
intercomunicanti su un singolo Transputer sono molto diversi 
da quelli sparpagliati su più unità. L’approccio originale a que¬ 
sto problema era quello di costringere a codificare (e a eseguir¬ 
ne il post-link) ogni parte del software per un hardware 
specifico. Potevamo perciò decidere di creare il nostro pro¬ 
gramma in modo che girasse su sei Transputer, ma questo non 
avrebbe poi potuto essere eseguito su cinque e avrebbe spreca¬ 
to quelli in eccesso se ce ne fossero stati più di sei, a meno di 
non modificare e ricompilare il sorgente. 

La prima soluzione a questo problema venne fornita nel com¬ 
pilatore Parallel C della 3L e poi nei seguenti compilatori For¬ 
tran e Pascal. Questi, oltre a fornire delle routine di 
configurazione generale assai più flessibili, permettevano an¬ 
che di riempire un qualsiasi numero di CPU con processi slave 
(figli) controllati da un unico processo master (padre). L’unico 
punto negativo consisteva nel fatto che i processi slave dove¬ 
vano essere tutti uguali. 

Chiaramente, per superare queste difficoltà, è necessario un si¬ 
stema operativo di qualche tipo ed Helios è ormai maturato ab¬ 
bastanza da permettere di configurare arbitrariamente un 
numero qualsiasi di task in un numero qualsiasi di processori. 
Il mio tentativo di scrivere un sistema operativo, Mercury, è 
molto più semplice di Helios, ma offrirà anch’esso la possibili¬ 
tà di configurare i task durante il caricamento, cosicché il soft¬ 
ware possa finalmente essere relativamente indipendente 
dall'hardware. 

L’obiettivo 

L'elaborazione parallela è diventata rapidamente una delle 
branche più famose del mondo moderno dei computer, sebbene 
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le argomentazioni a suo favore siano generalmente poco com¬ 
prese e portino alla ripetizione. Non appena fu sviluppato il 
primo calcolatore elettronico degno di questo nome, gli acca¬ 
demici iniziarono a speculare su quanto veloce sarebbe potuto 
diventare. C’è. naturalmente, un limite al flusso di dati di un 
processore, anche se questo limite è stato regolarmente innal¬ 
zato nel corso dell’ultimo decennio. 

Per ottenere le velocità di elaborazione veramente veloci di un 
supercomputer Cray o CDC, i trucchi per mantenere alto il 
flusso di dati sono diventati straordinariamente costosi: raffred¬ 
damento con liquido, semiconduttori molto costosi e così via. 
L’elaborazione parallela, quindi, dovrebbe essere anche una 
maniera molto economica di ottenere risultati paragonabili (o 
anche migliori). In realtà l'elaborazione sequenziale (anche su 
un Cray) risulta assai inefficiente per molte applicazioni che 
sono invece ideali per l’uso di metodi di elaborazione parallela 
quali le simulazioni di Monte Carlo e di altri modelli, analisi 
degli elementi finiti in ingegneria e così via. 

1 benefici ottenuti dall’inserimento dei Transputer in Amiga 
non sono ben definiti. Gli esempi insignificanti come quello 
che cita i benefici ottenuti nel calcolo della serie di Mandelbrot 
sono molto comuni ma di poca efficacia. Le tecniche di ray- 
tracing di Eric Graham sono mature per un tocco di paralleli¬ 
smo, così come lo sono i programmi seri per la grafica e il 
CAD. Le idee più innovative come quella dei processori di do¬ 
cumenti basati sull’AI (Artificial Intelligence) e quella dei si¬ 
stemi esperti multi-mediali potrebbero diventare obiettivi a 
lungo termine. 

La maniera più diffusa nella quale l’utente vede i risultati pro¬ 
dotti dal nostro software è attraverso lo schermo, che può esse¬ 
re controllato da Amiga o da un Transputer. Se è l'Amiga a 
dovere visualizzare i risultati e la grafica, allora in molti casi 
finiremo davvero per utilizzare i Transputer come coprocesso- 
ri, altrimenti l’overhead (il tempo aggiuntivo) richiesto dalle 
operazioni di comunicazione diventerebbe eccessivo. Questo 
approccio risulterebbe economico e potenzialmente adatto al 
mercato di massa. 

Ad ogni modo, per portare la grafica al livello dei Transputer, 
permettendo a programmi completi di girare su di essi, sarebbe 
necessaria una scheda grafica basata sui Transputer. a costi 
considerevolmente più elevati. Amiga verrebbe allora ridotto a 
una tastiera, a poche porte di I/O molto lente e a un lento siste¬ 
ma di memorizzazione su disco. Dal momento che i PC stanno 
già ricoprendo questo ruolo nei sistemi basati su Transputer at¬ 
tuali, a un prezzo molto più ridotto, vedo poche possibilità di 
vendita in questo caso. 

Qualsiasi cosa la Commodore voglia vedere fare a un Transpu¬ 
ter in un Amiga va messo nel contesto dei loro concorrenti. La 
MicroWay è ormai la più grande produttrice di schede Tran¬ 
sputer e le fabbrica solo per i PC. E in grado di offrire una serie 
completa di schede, inclusi sistemi grafici superbi, hard disk 
ultra veloci e schede I/O più specializzate. E una società ben 
affermata che vende ai settori corporativi e accademici, così 
come fanno i loro concorrenti, i quali offrono anch’essi prodot¬ 
ti basati su PC. 


La Levco offre attualmente una serie di costose, ma ben sup¬ 
portate, schede per il sempre più popolare Macintosh e gode 
addirittura di supporto a livello di programmazione dalla stessa 
Apple. Atari sta chiaramente investendo molti soldi nella sua 
workstation, l’ATW. sebbene il suo successo a lungo termine 
sia messo in dubbio da alcuni. 

Potrà, la scheda della Commodore, rendere superata l'ATW? 
Potrà competere con il massiccio mercato dei PC? 

Ho la sensazione che, perché questo possa succedere, dovrà es¬ 
sere estremamente economica, semplice, ma fortemente sup¬ 
portata dai talenti di Amiga, single user e single tasking (tenete 
a mente che i Transputer sono molto più fragili persino del 
68000, quando si usano in multitasking e sono inoltre privi di 
qualsiasi hardware per la gestione della memoria). 

La strada attuale 

Quello che è stato ufficialmente annunciato finora è che la 
Commodore ha prodotto una serie di quantità limitate di sche¬ 
de Transputer per Amiga 2000. Queste dovrebbero permettere 
l’uso di fino a 17 Transputer montati internamente, con la pos¬ 
sibilità di usarne uno addizionale per la grafica (anche se que¬ 
sto richiede misteriosamente l'uso di uno slot PC. forse perché 
si tratta di una scheda per PC e non per Amiga). Il software di 
sistema sarà Helios della Perihelion, sviluppato con successo 
da Tim King, architetto dell’AmigaDOS e dal suo team. 

Helios, dopo una partenza incerta, è oramai un prodotto maturo 
e abbastanza stabile. Il team ha dedicato molta attenzione a 
produrre un sistema operativo UNIX compatibile con pochi vi¬ 
zi (il peggiore dei quali è forse rappresentato dall'assenza di 
qualsiasi mezzo atto a intervenire in caso che il passaggio di un 
messaggio fallisca) e molte virtù. E abbastanza robusto nel 
multitasking e nel multiuser fino a potere essere impiegato nel¬ 
la rete di un grosso campus universitario che colleghi gruppi di 
Transputer sparsi negli edifici locali. Anche il server XWin- 
dows è stato al centro di un grosso lavoro per ridurne le dimen¬ 
sioni del codice e dei dati, per renderlo più maneggevole, 
almeno nei casi in cui ci siano pochi Transputer nel sistema. 

In ogni caso, ci sono ancora delle piccole pecche associate a 
Helios. Naturalmente impone un po' di overhead sia in termini 
di velocità di elaborazione che in termini di memoria occupata, 
sebbene sia difficile fare paragoni per trarne delle percentuali 
precise. Originariamente sembrava molto povero nella confi¬ 
gurazione di programmi su array differenti di processori, ma la 
Perihelion. per risolvere questo problema, ha prodotto un su¬ 
perbo linguaggio per la descrizione e la suddivisione di un pro¬ 
cesso. Comunque sia. ho paura che molti utenti non saranno 
semplicemente in grado di utilizzarlo, avendo bisogno di un 
metodo molto più intuitivo per costruire la complessità di task 
che formeranno i loro programmi. 

La combinazione dell’hardware Commodore e del sistema 
operativo Helios non sembra adatta per usare i Transputer co¬ 
me coprocessori. Sebbene siano forniti di DMA per accelerare 
il trasferimento di dati, ci sarebbe bisogno anche del supporto 
per un uso portato al limite dei coprocessori (senza passare at- 
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traverso il sistema operativo) e di buone librerie di funzioni. 
Nonostante queste possano essere già in fase di sviluppo, non 
sarà molto facile che appaiano prima che Helios venga installa¬ 
to e ne saranno sicuramente adombrate. 

Ogni volta che sento parlare di sistemi UNIX o UNIX-compa- 
tibili, divento assai poco interessato e ho paura che un numero 
sempre maggiore di utilizzatori di computer abbia la stessa rea¬ 
zione. La Apple ha imparato una lezione che la Commodore 
dovrebbe tenere da conto: il simil-UNIX-Macintosh , l'A/UX, 
è solo un aiuto nella vendita alle grosse organizzazioni quando 
sono già presenti tutti i collegamenti fra mini e mainframe. 1 
Mac-entusiasti evitano A/UX e le riviste come MacTutor lo 
menzionano appena. Non conosco ancora nessuno che lo ado¬ 
peri, nonostante abbia molti contatti con possessori di Mac II. 

Pensa forse, la Commodore, che a tutt’oggi vende ancora solo 
PC nel mercato delle grosse organizzazioni, di avere successo 
là dove la Apple ha subito una dura lezione, alla faccia del 
NeXT di Steve Jobs, dell’ATW e della sua scatola (e di molte 
altre scatole prodotte da altri) con 680x0? 

Chi vince? 

Senza dubbio, i prodotti Commodore terranno contenta la pic¬ 
cola ma vocifera banda di Amigix , di quelli che. per una ragio¬ 
ne o per l’altra, pensano che Amiga possa veramente evolversi 
per diventare una macchina UNIX. I prodotti Commodore, 
probabilmente, faranno anche qualche danno all’ATW Atari, 
anche se penso che se il prodotto di una delle due fallirà, lo fa¬ 
ranno entrambi. 

Rifuggo con orrore la prospettiva di provare a utilizzare la 
scheda Commodore come coprocessore. anche senza Helios e 
con il suo DMA. Qualcuno dovrà scrivere quelle librerie e que¬ 
sto qualcuno avrà più di qualche semplice problema a cui pen¬ 
sare. Uno dei vantaggi della RAM a due porte consiste nella 
possibilità di invertire l’ordine dei byte durante il processo di 
trasferimento, cosa abbastanza importante se dovremo trasferi¬ 
re insiemi misti di tipi interi e reali fra processori che vedono 
l’ordine dei byte esattamente in maniera opposta! 

C’è poi il problema di assicurarsi che solo i pezzi giusti del co¬ 
dice vengano caricati nella memoria interna dei Transputer, al¬ 
trimenti questi diventeranno pietosamente lenti anche in 
paragone a un 68030 con coprocessore 68882. 

Se, quindi, state sviluppando silenziosamente una scheda Tran¬ 
sputer che può essere prodotta in maniera economica e che cal¬ 
za nel ruolo di coprocessore. fatemelo sapere. Magari, dopo 
tutto, l’interesse principale della Commodore non sta nella 
commercializzazione del suo prodotto, che è già vecchio di un 
anno, ma nel suo uso interno per lo sviluppo e l’addestramento 
su un nuovo chip che sarà ancora meglio dei Transputer e che 
formerà la base della nuova generazione di Amiga. Nel frat¬ 
tempo, io ho solamente voglia di mettere il mio processore fa¬ 
vorito nel mio microcomputer preferito. 
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Breakpoint 


Il debugging con i programmi di Manx e Lattice 


di Victor A. Wagner 


Vie Wagner iniziò ad avere a che fare con i calcolatori nel 
1965 quando divenne parte di un gruppo di studio della US Air 
Force sulla simulazione digitale del volo. Tornato un civile nel 
1966. ha lavorato principalmente con costruttori di minicom¬ 
puter. nel campo del software per sistemi in tempo reale. Nei 
giorni feriali dalle 8 alle 17, Vie cura la consulenza tecnica te¬ 
lefonica per la Computer Automation Ine. e la manutenzione 
del software di tre sistemi in tempo reale. Alla sera e nei fine 
settimana, trascorre il suo tempo conversando con Taarna (il 
suo Amiga 1000), scrivendo programmi e collegandosi ad 
AmigaForum. Vie è, inoltre, un’autorità riconosciuta per 
quanto riguarda il famoso programma di debugging MetaSco- 
pe prodotto dalla Metadigm Ine. 

In questi ultimi tempi un nuovo programma della Lattice, Co- 
dePRobe, si è aggiunto alla lista dei debugger che lavorano su 
Amiga. Non sono forse carini questi nomi che la gente sceglie 
abilmente per i loro prodotti? CodePRobe, con le lettere CPR 
maiuscole. 

Siccome CodePRobe è la novità più calda nel campo dei de¬ 
bugger (beh, è comunque la più recente) ho pensato di trattarlo 
in questa puntata. Naturalmente parleremo anche di SDB (della 
Manx) in quanto questi sono gli unici due source debugger (per 
source debugger si intende un debugger che offre la possibilità 
di vedere e di operare sul codice sorgente durante il debug¬ 
ging) attualmente disponibili. Daremo un’occhiata agli altri de¬ 
bugger in una prossima puntata (ammesso che le mie dita 
riescano ancora a trovare la tastiera). 

Si vocifera che dei source debugger siano in preparazione an¬ 
che alla Avant-Garde ( Benchmark Modula-2 ) e alla Metadigm 
(come upgrade del Metascope). 

Sto anche tentando di scoprire che fine farà il programma LDe- 
bug (SoftCircuits) dal momento che i produttori sembrano es¬ 
sere andati in fallimento e dal momento che la mia copia 
sembra essere sparita. 

Ad ogni modo, questa volta vedremo come funzionano i cosid¬ 
detti ’source’ debugger e cosa rappresentano per quelli di noi 
che scrivono in C. Sebbene la definizione del formato dei file 
object preveda, fin dal primo giorno di disponibilità di Amiga, 


la presenza al loro interno di informazioni utili al debugging, 
nessuno standard è stato ancora pubblicato per stabilire come 
dovrebbero essere, in pratica, queste informazioni. Come risul¬ 
tato, si sono sviluppate diverse tecniche per fare arrivare ai de¬ 
bugger le informazioni necessarie. 

Se me lo permettete, a questo punto vorrei inserire un com¬ 
mento editoriale: gran parte delle ragioni per cui Amiga sta 
avendo un tale successo va sicuramente attribuito allo standard 
IFF. Trovo che sia piuttosto deludente il fatto che, più il tempo 
passa, più questo affermato standard viene eroso dalla compar¬ 
sa di nuovi prodotti di compagnie che devono fare cose specia¬ 
li. 

Mi spiace dover riferire che nel mondo dei source debugger le 
informazioni in questione non sono simili neanche nel formato. 
Il prodotto della Manx le scrive in un file separato, mentre 
quello della Lattice le seppellisce nel file eseguibile (come per¬ 
messo nelle specifiche originali). 

Sfortunatamente ognuna delle due compagnie sembra pensare 
che queste informazioni siano di carattere riservato. Natural¬ 
mente ciascuna delle due fornisce agli utenti un programma 
che decifra queste informazioni. 

Capisco il desiderio di avere il migliore prodotto in circolazio¬ 
ne e anche quello di avere un margine di vantaggio sulla con¬ 
correnza. Quello che non capisco è questo desiderio di 
possedere le fette di mercato come motivazione principale del 
proprio operato. L'introduzione di sistemi e di pacchetti soft¬ 
ware strettamente riservati condurrà al disastro che già attana¬ 
glia il mondo dei PC ( mucchi di programmi, ma nessuno riesce 
a comunicare con un altro). 

Bill Volk (prima alla Aegis, adesso alla Mediagenics) ha rias¬ 
sunto la situazione nel migliore dei modi: "non voglio una fetta 
più grande della torta, voglio torte più grandi". Il modo di ave¬ 
re torte sempre più grandi consiste nello scambio di informa¬ 
zioni e nella cooperazione delle compagnie che sviluppano 
software, anche se si tratta solamente di scambiare il fonnato 
dei dati esterni. 

Ok, adesso basta, torniamo ai nostri due programmi. 
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Se qualcuno, nel lontano 1966. mi avesse detto (o avesse an¬ 
nunciato al mondo dei computer in generale) che in futuro sa¬ 
rebbero diventati disponibili programmi come SDB e 
CodePRobe, l’avremmo probabilmente rinchiuso in una came¬ 
ra d’isolamento. 

Naturalmente, a quei tempi, una macchina grossa aveva 128K. 
Le informazioni di debugging necessarie a tenere sotto control¬ 
lo un programma di medie dimensioni, specialmente un pro¬ 
gramma Amiga con tutte le sue strutture di sistema, superano 
da sole abbondantemente i 128K. 

Okay, diamo un’occhiata agli aspetti esteriori dei debugger pri¬ 
ma di addentrarci nei particolari del loro funzionamento. 

cpr 169392 -arwed 07-Nov-88 15:13:40 

sdb 89228 -rwed 24-Jan-88 01:43:48 

Come potete vedere, CodePRobe è sostanzialmente più lungo, 
visto come file su disco. Una volta caricati in memoria, sulla 
mia macchina, le dimensioni assumono un aspetto simile: 


che ci accompagnano in alcune sessioni di debugging a titolo 
di esempio. 

Ragazzi, questo è uno di quei casi in cui è altamente racco¬ 
mandabile leggere prima il manuale. Sebbene entrambi i pro¬ 
grammi abbiano interfacce ben pensate, non posso definire 
nessuna delle due con l'aggettivo "intuitiva". Per favore, non 
prendete questo commento come critica; imparare a usare un 
programma così complesso, come nel caso di questi due, è co¬ 
me imparare un nuovo liguaggio. 

Le persone che hanno scritto questi programmi usano nomi dif¬ 
ferenti per le stesse cose, così le abbreviazioni e i comandi so¬ 
no alquanto diversi. 

Fianco a fianco 

Appena lanciamo i due programmi notiamo delle differenze. 
SDB ha una finestra speciale 3-in-l che si apre a 640x200. Co¬ 
dePRobe apre due delle possibili quattro finestre e ne aggiusta 
automaticamente le dimensioni per riempire uno screen delle 
stesse dimensioni di quello del Workbench. 


CodePRobe: size 

1 

1 

SDB: 


size 

La finestra 3-in-l può essere ridimensionata almeno fino a 

address 

Hex 

Dee 

1 

1 

address 

Hex 

Dee 

680x432, nel qual caso le dimensioni delle finestre interne ven¬ 
gono aggiustate in modo proporzionale. Vi potreste chiedere 

0296F0 

224 

548 

1 

814F10 

4 

4 

perché la chiamo 3-in-l se contiene due finestre interne ridi- 

840660 

50 

80 

1 

8428A0 

214 

532 

mensionabili. 

842640 

1680 

5760 

1 

87A188 

2058 

8280 


87A188 

7300 

29440 

1 

87C1E8 

7 6D4 

30420 

Ebbene, una delle parti è alta solo una linea ed è la parte dove 

881490 

6C7C 

27772 

1 

8838C8 

2B88 

11144 

appare tutto quello che digitiamo. La finestra al di sopra di 

888118 

75B4 

30132 

1 

886458 

20 AC 

8364 

questa linea è dove appare il codice sorgente e quella al di sot¬ 

88F6D8 

7B7 0 

31600 

1 

888510 

2330 

9008 

to è dove appaiono i risultati dei comandi che diamo. Il rappor¬ 

89EFD0 

69D0 

27088 

1 

88A848 

3B54 

15188 

to di queste due finestre si può modificare selezionando con il 


====== 

====== 

1 

88E3A8 

26A0 

9888 

mouse un gadget all'estremità destra della linea di comando e 

total 

2D0D8 

184536 

1 

1 

1 

1 

890A50 

892AB8 

total 

2060 

200C 

1AB08 

8288 

8204 

109320 

spostandola in su o in giù. La linea di comando si sposta nella 
nuova posizione e le finestre del codice sorgente e dei risultati 
si espandono e si contraggono di conseguenza. Mi piace l'idea 
della linea di comando per l’input, in quanto non sottrae spazio 
nella finestra di visualizzazione per ogni comando eseguito. 


Ricordate, e se non lo ricordate consultate l'articolo "La strut¬ 
tura di un programma Amiga" su questo stesso numero, che 
Amiga esegue il 'caricamento sparso’ (scatter loading). Gli in¬ 
dirizzi non sono quindi di particolare interesse, ma le dimen¬ 
sioni degli hunk mostrano che CodePRobe è più grande anche 
una volta caricato in memoria. 

Un’altra differenza nell’aspetto consiste nel fatto che Code¬ 
PRobe viene fornito con un solenne e imponente manuale (6.5" 
x 9") di 138 pagine con indice e tavola dei contenuti. SDB vie¬ 
ne fornito con un manuale (5.5" x 8.5") di 66 pagine. 

Entrambi sono ben scritti e si presentano bene. Assumendo che 
abbiate ormai imparato come leggere un manuale, non dovre¬ 
ste avere alcuna difficoltà con essi. 

Il manuale di SDB ha una sezione chiamata "tutorial" e quello 
di CodePRobe una chiamata "walkthrough". Entrambe sono 
utili da leggere nel caso si intenda utilizzare effettivamente il 
programma. SDB viene fornito con alcuni script dimostrativi 


Dall’altra parte, CodePRobe usa una finestra per il dialogo 
utente/programma abbastanza immediata. Ricorda abbastanza 
una finestra CLI nel senso che si vede quello che digitiamo in 
fondo e il contenuto della finestra scrolla verso l’alto, proprio 
come siamo abituati. Entrambi i programmi offrono la possibi¬ 
lità di richiamare i comandi già inseriti (history) e di modifi¬ 
carli (editing). 

Una grossa differenza che ho notato sta nel fatto che SDB non 
può essere usato con un programma che non sia stato compila¬ 
to in modo da avere il relativo file .dbg, mentre CodePRobe 
permette almeno di ottenere il disassemblato del programma e 
di lavorare a quel livello. 

Fare il debugging con questi programmi è una vera gioia se si 
fa un paragone con tutti quelli che ho usato prima di passare su 
Amiga. Per me è semplicemente meraviglioso poter mettere un 
breakpoint alla linea 65 del file attuale e poi esaminare il con¬ 
tenuto delle variabili (perfino per nome) per poi decidere cosa 
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fare in seguito. 

guardando l’output assembly, si avanzerà di istruzione in istru¬ 
zione, mentre se stiamo guardando solamente l’output C il pas- 

Entrambi i programmi dispongono di svariati modi per mettere 
i breakpoint. per associarvi espressioni condizionali (cosicché 
interromperanno l'esecuzione solo quando la condizione sarà 
soddisfatta), per eseguirli un numero ennesimo di volte prima 
di fermarsi e così via. Sono, insomma, in grado di scatenare le 
fantasie più selvagge. 

so sarà di una linea di sorgente alla volta. Se si continua per un 
certo tempo in queste operazioni, il contenuto della finestra 
sorgente si sposterà automaticamente per mantenere la porzio¬ 
ne di codice sotto esame visibile sullo schermo. 

Naturalmente ci si può avvantaggiare anche di una barra di 
scroll che entrambi i programmi mettono a disposizione. Non 

Ci sono anche breakpoint temporanei e permanenti. Possiamo 
perfino dire al debugger di eseguire alcuni comandi quando 
l'esecuzione viene interrotta. I più utilizzati, in quest'ultimo 
caso, saranno i comandi di visualizzazione o stampa, ma le 
possibilità sono infinite. 

abbiamo neanche bisogno di fare girare il nostro editor per esa¬ 
minare il sorgente, in quanto possiamo farlo comodamente al¬ 
l’interno del debugger. SDB mette a disposizione perfino il 
comando find string per cercare una determinata stringa all’in¬ 
terno del sorgente. Entrambi effettuano una numerazione delle 
linee del sorgente e i linguaggi di programmazione di ognuno 

Parlando di funzioni di visualizzazione e stampa, entrambi i 
debugger ci permettono di esaminare la memoria in qualsiasi 
formato possa mai essere desiderato. Per esaminare una zona 
di memoria qualunque, possiamo guardare i dati sotto forma di 
byte, word (Manx) o short (Lattice), long, puntatori, stringhe, 
float e la lista continua, continua, continua... 

permettono l’uso dei numeri di linea con comandi tipo break. 

CodePRobe permette di evidenziare una linea (selezionandola 
due volte con il mouse), mettendo contemporaneamente un 
breakpoint permanente a quell’indirizzo (sebbene non abbia 
trovato alcuna informazione su tutto ciò nel manuale). Selezio- 

Penso che tutti questi comandi siano stati implementati per noi¬ 
altri vecchi individui dalle idee arretrate che le abbiamo usate 
per decenni. La parte veramente eccitante viene quando il pro¬ 
gramma è stato compilato con le opzioni appropriate in modo 
che il debugger possa vedere il tipo delle variabili. Adesso tut¬ 
to quello che dobbiamo fare è dire al programma di stampare 
una variabile e questa verrà visualizzata sullo schermo nel for¬ 
mato corretto. 

nando nuovamente due volte quella linea il breakpoint verrà ri¬ 
mosso. Sfortunatamente dopo questa operazione la finestra di 
comando non risulta attiva (la finestra di display diventa attiva 
quando clicchiamo in essa), così non possiamo scrivere sempli¬ 
cemente g (abbreviazione di go) per spostarci a quel break¬ 
point. Beh, questo è uno svantaggio minimo in confronto alla 
possibilità di selezionare una linea col mouse al fine di attivare 
un breakpoint in quel punto. Apparentemente SDB non usa il 
mouse per alcuna operazione (eccetto che per lo scrolling). 

Possiamo perfino visualizzare una struttura dati, nel qual caso 
tutti i suoi membri verranno stampati nel loro formato corretto, 
addirittura ciascuno con il suo nome. SDB menziona esplicita¬ 
mente il fatto che esiste un metodo particolare per esaminare i 
parametri di una funzione. Sospetto che lo possa fare anche 
CodePRobe, ma non mi sono ancora imbattuto nella spiegazio¬ 
ne relativa all’interno del manuale. Se avete l’impressione che 
io sia stato sopraffatto da questi programmi, avete ragione. 

Entrambi i programmi hanno la capacità di togliersi di torno 
quando il programma sta girando. In CodePRobe, la funzione 
autoswap (così è chiamata) è normalmente ON, al contrario di 
SDB nel quale è OFF. Questa funzione può diventare fastidio¬ 
sa, ma si può disattivare facilmente. I tasti di funzione servono 
in entrambi i programmi a passare dalla finestra del debugger a 
quella del programma in prova e viceversa. 

Ci vorrà sicuramente del tempo per adattare le mie tecniche di 

Facciamo una prova! 

debugging a questi due programmi. Da svariati anni a questa 
parte, per esempio, ho utilizzato i breakpoint dei debugger qua- 

Diamo un’occhiata a una semplice sessione di lavoro con que¬ 
sti due programmi, tanto per avere un'idea di quello che è pos¬ 
sibile fare. 

si esclusivamente all’ingresso delle funzioni e nelle locazioni 
di ritorno da esse. 

Assumeremo di avere compilato ed eseguito il link del pro¬ 
gramma con successo e che quindi si sia poi lanciato il debug¬ 
ger. In circostanze normali questi visualizzerà il sorgente del 
nostro programma nella finestra superiore, con la prossima li¬ 
nea da eseguire evidenziata in qualche maniera. 

La mia prima azione quando si raggiunge un breakpoint all'ini¬ 
zio di una funzione consiste nel trovare e visualizzare gli argo¬ 
menti. Ho scoperto che entrambi i programmi hanno un 
singolo comando per espletare questo compito, ds per SDB e 
where per CodePRobe. Ma questi sono in realtà dei comandi di 
backtrace per lo stack. Essi visualizzano tutte le funzioni che 
sono state chiamate finora e anche tutti i relativi argomenti. 

Se vogliamo dare un’occhiata al codice generato dal compila¬ 
tore (neanche io mi fido mai del mio compilatore), esiste 
un’opzione che permette la visualizzazione di sorgente C com¬ 
binato con le relative istruzioni assembly. 

Vorrei che ci fosse un semplice comando per visualizzare sola¬ 
mente la situazione attuale e magari anche le variabili locali. 

Un altro comando che mi piacerebbe vedere implementato è 
"fermati dopo che questa funzione è finita". So come trovare 

Come passo successivo premiamo il tasto giusto per fare ese¬ 
guire una singola istruzione dal debugger (single step). La zona 
evidenziata si sposta alla prossima linea da eseguire. Se stiamo 

l'indirizzo di ritorno di una funzione e come metterci un break¬ 
point, ma un semplice comando per fare fermare l’esecuzione 
del programma in quel punto sarebbe comodo. Beh, magari 
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non ho veramente utilizzato questi due debugger per un tempo 
abbastanza lungo da poter acquisire fluidità nel loro uso. Ma¬ 
gari in futuro troverò un modo diverso, migliore, di fare il de¬ 
bugging con l'ausilio di questi due nuovi programmi. 

La filosofia del debugging 

C’è la tentazione, quando si usano questi programmi, di presta¬ 
re meno attenzione durante la scrittura del codice (e anche du¬ 
rante una sessione di debugging). Sono convinto, ormai da 
parecchio tempo, che mettere un breakpoint in un programma 
sia molto simile ad affrontare un test con scelta multipla. Que¬ 
sto vuole dire che dovremmo già avere deciso quale, secondo 
noi, è la risposta giusta, prima di vedere quali sono quelle di¬ 
sponibili. 

Ebbene, con un computer e un breakpoint si ha una sola scelta, 
ma l’idea è quella di decidere prima di premere il bottone. Sor¬ 
gono sempre problemi quando si lascia che sia il nostro pro¬ 
gramma a dirci qual’è la risposta e si tenta a posteriori di 
decidere se il nostro programma ha ragione oppure no. 

A questo punto abbiamo molti fattori che giocano contro di 
noi. Per prima cosa, il nostro bambino (il programma) ha appe¬ 
na prodotto questi risultati. Come potrebbe, una creatura così 
meravigliosa, avere torto? Secondariamente, è stato dimostrato 
ripetutamente che una figura autoritaria che produca una solu¬ 
zione può fare propendere anche la persona più cinica a pensa¬ 
re che lui abbia la risposta giusta. 

Se avete dei dubbi sul fatto che un computer sia una figura au¬ 
toritaria, provate a recarvi in amministrazione e a spiegare che 
il computer deve avere fatto qualche errore nell’ultima busta 
paga. 

Lasciate che vi racconti una storia 

Ho visto sin troppe volte i computer intimidire la gente e con¬ 
vincerli a credere che loro avevano ragione, quando tutto il 
buon senso indicava diversamente. Questi computer e i loro 
programmi intimidiscono perfino gli stessi autori dei program¬ 
mi... se li lasciamo fare. 

L’esempio più clamoroso di tutto questo, che io abbia mai avu¬ 
to modo di vedere, riguardava un programmatore che stava 
scrivendo un programma di diagnostica per un computer com¬ 
pletamente nuovo. In questo caso il programmatore affrontava 
due incognite: una macchina che non aveva mai eseguito una 
qualsiasi istruzione prima d’allora e un programma che era sta¬ 
to appena terminato. 

In sua difesa devo far presente che i nostri ingegneri accesero 
per la prima volta la macchina verso le 10 di sera per fare la 
prova iniziale con il programma di diagnostica. Era stata una 
giornata molto lunga e, senza ombra di dubbio, il programma 
di diagnostica stava segnalando che qualcosa non andava per il 
verso giusto nel nuovo computer. Non era una grossa sorpresa 
e dal momento che la macchina aveva appena eseguito la sua 
prima istruzione in assoluto, dovrebbe essere ovvio che questo 
programma non era mai stato eseguito prima. 


Ad ogni modo, a mano a mano che i problemi del nuovo de¬ 
sign (hardware) venivano localizzati e risolti, così come veni¬ 
vano trovati e risolti anche alcuni problemi nel programma di 
diagnostica. Cari iniziò ad assumere un certo tipo di approccio, 
che consisteva, appena un test indicava un problema, nel ripor¬ 
tare indietro il program counter ed eseguire il test passo per 
passo. Sfortunatamente non si poneva a priori il problema di 
quale risultato il programma avrebbe dovuto produrre. Guarda¬ 
va i risultati mano a mano che venivano prodotti e poi diceva 
’yae’ o ’nae’. 

Come avrete probabilmente indovinato, c’era effettivamente 
qualcosa di sbagliato nell’hardware della nuova macchina, e la 
combinazione del fare le ore piccole e del non pensare alle ri¬ 
sposte prima che i risultati fossero disponibili cospirò nel con¬ 
vincere Cari che il suo programma di diagnostica era sbagliato 
e che la macchina stava effettivamente funzionando corretta- 
mente. 

La storia ha un lieto fine. Il computer con numero seriale 0003 
fu spedito a un potenziale acquirente che individuò il particola¬ 
re problema quasi immediatamente. Sembra che il problema 
fosse abbastanza frequente nei computer nuovi e quindi l’inge¬ 
gnere/il programmatore del cliente aveva effettuato un test 
esplicito per individuarne l’eventuale presenza. 

Mi recai nella sede di questo cliente all'incirca dopo due giorni 
che questa macchina era stata recapitata. Era più divertito che 
irritato, ma fece presente che sarebbe stato meglio riparare il 
computer. 

Ero quasi incredulo sul fatto che l'errore potesse esistere. Ave¬ 
vo (e ho tuttora) il più grande rispetto di Cari come program¬ 
matore (e cacciatore di bug). Non potevo credere che non 
avesse verificato questo tipo di bug sui confini (boundary), co¬ 
sì chiamai l'ufficio e chiesi: 

"Certo che l'ho provato, perché?" fu la risposta di Cari. 

"Perché il programma di diagnostica non segnala problemi a 
questo proposito, ma quando lo codifichiamo a mano il test sui 
confini fallisce" risposi. 

Cari esaminò nuovamente con attenzione il programma di dia¬ 
gnostica. Il test era effettivamente lì, ma il programma funzio¬ 
nava al contrario, verificava la risposta sbagliata. Cari e io ci 
facemmo sopra qualche risata e qualche birra, quando tornai in 
ufficio e riferii tutta la storia, ma tutta l’avventura sottolinea 
l’estrema importanza di fare dei test in maniera accurata. 

Ci sono persone che non sono d’accordo con me nel ritenere 
che si dovrebbe stabilire con accuratezza quale dovrebbe esse¬ 
re la risposta di un certo programma, funzione, istruzione, pri¬ 
ma di dare al calcolatore la possibilità di fornirla. La mia 
opinione personale è che quelli di noi che utilizzano un diverso 
tipo di approccio andrebbero classificati come smanettoni anzi¬ 
ché come programmatori. 


Continua a pagina 61 
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I device di Amiga -1 


Un primo sguardo a ciò che rende unico Amiga 


di Betty Clay 

I device sono di importanza vitale nel funzionamento di Ami¬ 
ga. Il trackdisk.device controlla i nostri disk drive, Vaitdio.de- 
vice permette ad Amiga di parlare e così via. Quando diamo il 
comando Assign. possiamo ottenere la lista di una dozzina o 
più device che sono attivi in quel momento nel sistema. Nel 
mio computer sono attualmente attivi i device Pipe:, Aux:, 
Speak:. Newcon:, VDK:, DF2:. DF1:, DFO:, Prt:. Par:, Ser:, 
Raw:, Con: e Ram:. I nomi sono familiari e il compito di ognu¬ 
no di questi è conosciuto. Ma in che cosa consiste esattamente 
un device? E che cosa fa? 

Non è mia intenzione dire in queste poche righe a un program¬ 
matore avanzato come scrivere un nuovo device per Amiga, 
ma chiarificarne il concetto a beneficio mio e degli utenti che 
ricadono nella fascia compresa fra i principianti e i medio¬ 
avanzati. I programmatori avanzati possono invece trovare si¬ 
curamente più interessante l’articolo di Steve Simpson 
contenuto in questo stesso numero. Inoltre, Mortimore ha 
riempito un intero libro di informazioni sui device e tutti quelli 
che desiderano implementarne uno dovrebbero prima consult¬ 
arlo (Amiga Programma 's Hartdhook, volume II, Eugene P. 
Mortimore, Sybex). 

II termine device viene usato in almeno due modi differenti. 
Alcune volte parliamo di device come di un qualcosa facente 
parte dell’hardware, come un disk drive o la porta seriale, ma 
potremmo anche parlare di questi device fisici come di unità 
controllate da un device. Nell’ambiente Amiga è più accurato 
parlare di un device nel senso del software che controlla il de¬ 
vice fisico. Un device Amiga controlla uno o più device fisici, 
ognuno dei quali rappresenta un’unità separata. Ma anche qui 
usiamo la parola unit per riferirci sia all’hardware che al soft¬ 
ware. Che confusione! 

Quando ho chiesto agli esperti (ho consultato tutti i libri dipo- 
nibili per Amiga), ho trovato diverse definizioni di device. Tut¬ 
ti erano comunque d'accordo sul fatto che device sia un 
concetto software e sembravano d’accordo anche sul fatto che 
un device sia un caso speciale di libreria di Amiga. Le librerie 
sono più facili da capire e sono meglio documentate, quindi ri¬ 
sulta più facile rispondere alla prossima domanda, "Che cos’è 
una libreria?". 


Le librerie di Amiga 

Ognuna delle librerie di Amiga consiste in tre parti pricipali: 

• una struttura Node. usata per collegarla al resto del sistema. 

• una serie di istruzioni di salto (jump table), che danno l'e¬ 
satta ubicazione delle sue svariate routine. 

• un segmento di dati proprio di ogni libreria. 

Per convenzione, l’indirizzo della libreria è rappresentato dal¬ 
l’indirizzo del primo byte della struttura nodo. I vettori della 
jump table si trovano a offset negativi (a indirizzi inferiori) ri¬ 
spetto a questo indirizzo di base, mentre i dati si trovano a off¬ 
set positivi (a indirizzi superiori). 

Il nodo di una libreria contiene questi elementi: 

struct Library { 

struct Node lib_Node; 

UBYTE lib_Flags; 

UBYTE lib_pad; 

UWORD lib_NegSize; 

UWORD lib_PosSize; 

UWORD lib_Version; 

UWORD lib_Revision; 

APTR lib_IdString; 

ULONG lib_Sum; 

UWORD lib_OpenCnt; 

1 ; 

• una struttura Node, che abbiamo già menzionato, usata per 
collegare la libreria al resto del sistema 

• un byte per i flag che segnalano se la libreria è valida, se il 
checksum è corretto ecc. 

• un byte di riempimento (pad) per assicurare il giusto alli¬ 
neamento, non utilizzato 

• una word (16 bit) contenente le dimensioni (espresse in nu¬ 
mero negativo) della jump table 
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• una word per le dimensioni (espresse in numero positivo) 
del segmento dati 

• una word per il numero di versione della libreria 

• una word per il numero di revisione della libreria 

• un puntatore alla stringa di identificazione, che può essere 
lunga fino a 255 caratteri 

• una longword (32 bit) per i! checksum della libreria 

• una word per tenere conto del numero di task che stanno 
usando questa libreria 

La struttura Node è la stessa usata in tutti i nodi del sistema. 
Qualsiasi cosa debba essere tenuta in una lista inizia con una 
struttura del genere. La sua composizione è molto semplice, 
lunga pochi byte e consistente in: 


struct Node { 


struct 

Node 

*ln Succ; 

struct 

Node 

*ln Pred; 

UBYTE 


In Type; 

BYTE 


ln_Pri; 

char 


*ln Name; 


} ; 

• un puntatore al nodo successivo della lista 

• un puntatore al nodo precedente della lista 

• un byte che specifica di quale tipo di nodo si tratti (device, 
font, interrupt, library ecc.) 

• un byte che definisce la priorità di questa struttura 

• un puntatore al nome di questo nodo 

Il byte ln_Type assicura che questo nodo venga messo nella li¬ 
sta di sistema appropriata quando viene caricato in memoria. Il 
byte ln_Pri stabilisce la posizione di questa struttura nella lista. 
Gli elementi con priorità più alta vengono messi in cima alla li¬ 
sta, assicurandogli un accesso più frequente alla CPU (nel caso 
si tratti di nodi task o process). Questo nodo non fa attivamente 
parte della libreria, ma funziona come mezzo per tenere in or¬ 
dine e sotto controllo le cose nel sistema. 

L’ultimo elemento della struttura Library, lib_OpenCnt, viene 
incrementato ogni volta che un task o un processo apre questa 
libreria e viene decrementato ogni volta che qualcuno la chiu¬ 
de. Quando questo contatore viene decrementato a zero, la li¬ 
breria può essere rimossa dalla memoria e questo succederà se 
la macchina è a corto della stessa. Il contatore garantisce che la 
libreria non verrà rimossa se qualcuno la sta ancora utilizzan¬ 
do. Le operazioni di incremento e decremento vengono effet¬ 
tuate automaticamente dal sistema ogni volta che un task apre 
o chiude la libreria. I programmatori non hanno bisogno di pre¬ 
occuparsi di nulla, eccetto che di chiudere la libreria quando 
hanno finito di utilizzarla. 


Quando un programma chiede di aprire una libreria (con la 
funzione OpenLibrary), viene esaminata una lista di sistèma 
per vedere se la libreria richiesta è già presente in memoria. In 
caso affermativo, il contatore lib_OpenCnt viene incrementato 
e al programma viene restituito l’indirizzo del primo byte della 
struttura Library (che coincide con l’indirizzo del primo byte 
della struttura Node, in quanto essa costituisce il primo mem¬ 
bro della struttura Library). In caso negativo, la libreria viene 
caricata in memoria, inserita nella lista di sistema, il contatore 
viene incrementato e, come prima, ne viene restituito l'indiriz¬ 
zo di base al programma invocante. 

L'ubicazione di una libreria contenuta nel Kickstart può essere 
differente per ogni versione del sistema operativo. Nel caso di 
una libreria che si trova su disco (nella directory LIBS:), l’ubi¬ 
cazione in memoria cambia ogni volta che la libreria viene ca¬ 
ricata, ma la posizione della jump table all’interno della 
libreria rimarrà sempre costante. Questo è il modo che permet¬ 
te al software di rimanere compatibile con macchine diverse o 
con versioni diverse del software di sistema. Se il programma¬ 
tore chiama una routine di una libreria seguendo il metodo 
standard, il sistema sarà sempre in grado di trovarla, non im¬ 
porta dove si trovi in quel momento. 

Ogni funzione avrà un offset negativo dall’indirizzo di base 
della libreria e i dati ne avranno uno positivo (da qui il motivo 
delle dimensioni negative e positive lib_NegSize, lib_PosSize). 
Ogni elemento della jump table è contenuto in sei byte: due per 
l’istruzione di salto (JMP) e quattro per l’indirizzo della routi¬ 
ne. Le routine vere e proprie possono essere posizionate in 
qualsiasi parte della memoria, ma i loro indirizzi verranno im¬ 
magazzinati nella jump table e da questa il task potrà rintrac¬ 
ciare le istruzioni che gli servono. 

Come fa un programma a sapere dove trovare una detenninata 
funzione, quando il sistema operativo gli fornisce solo l’indi¬ 
rizzo della libreria? 

Qui entrano in gioco il compilatore e il linker. Quando si ese¬ 
gue il link di un programma, il linker individua l’offset all’in¬ 
terno della jump table per ogni routine che il programma 
chiama e codifica questo offset nel programma. Durante l'ese¬ 
cuzione il programma si porta all’indirizzo base della libreria, 
quindi si sposta dell’offset fornito dal linker e salta all’indiriz¬ 
zo della vera routine. 

La parte contenente dati di una libreria può essere consultata 
da un task, ma normalmente contiene informazioni pertinenti 
solo alle routine interne della libreria stessa. In alcuni casi i 
corpi delle routine della libreria sono contenuti in questa sezio¬ 
ne. Questa parte della libreria non è così ben descritta e docu¬ 
mentata come il nodo e la jump table discussi in precedenza. 

I device 

Uno degli obiettivi dei progettisti di Amiga era di costruire 
ogni parte del sistema nella maniera più coerente possibile. 
Questo avrebbe significato facilità di programmazione. Nel ca¬ 
so dei device, comunque, questo si è rivelato estremamente dif¬ 
ficile. Una penna ottica non richiede, per esempio, gli stessi 
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comandi necessari per utilizzare un disk drive. Il timer.device 
ha bisogno di segnali di tipo diverso da quelli richiesti dall'au¬ 
dio.device. I device, quindi, sono stati codificati nella maniera 
più coerente possibile, ma ognuno di essi richiede routine spe¬ 
cializzate per lo svolgimento dei propri compiti e di cui è diffi¬ 
cile fare una trattazione generale. 

Quando un task apre un device chiamando OpenDevice, il si¬ 
stema operativo inizializza automaticamente una struttura De¬ 
vice e anche una struttura Unit, il cui membro unit_MsgPort 
servirà come message port per la particolare unità selezionata. 

Lo stesso device e la stessa unità possono essere condivisi da 
qualsiasi altro task in esecuzione e il membro lib_OpenCnt 
della struttura Device (lo stesso della struttura Library) terrà 

Siccome un device è derivato da una libreria, sappiamo che de¬ 
ve contenere un nodo come nelle librerie, una jump table per le 
funzioni del device e una struttura dati, e che queste devono se¬ 
guire le regole già viste per le librerie nel senso di avere degli 
offset negativi per la jump table e positivi per i dati. Ecco infat¬ 
ti come è definita la struttura device: 

conto del numero di task che li stanno usando. 

Un task userà una struttura di tipo IORequest per descrivere le 
sue necessità di dati e manderà questa richiesta alla porta della 
struttura unità. Il messaggio dirà al device quali dati vengono 
richiesti e dove metterli in memoria. Normalmente queste ri¬ 
chieste vengono soddisfatte sequenzialmente, chi arriva prima 

struct Device { 

struct Library dd Library; 

}; 

viene servito prima, ma in alcuni casi il task richiedente può 
specificare che la richiesta sia di tipo QuickIO, facendole salta¬ 
re la fila e ottenendo una risposta il più presto possibile. Il de¬ 
vice, comunque, è abbastanza intelligente. Se gli risulta 

Nel Rom Kernel Manna1 troverete una descrizione dettagliata 
di ciascun device, nella quale vengono analizzate le sue funzio¬ 
ni caratteristiche. Ma esiste anche una serie di funzioni stand¬ 
ard presenti in tutti. 

impossibile soddisfare questo tipo di richiesta immediata in un 
tempo ragionevolmente breve, la richesta non verrà respinta, 
ma verrà messa in coda come tutte le altre e processata quando 
arriverà il suo turno. 

La jump table di ogni device conterrà le chiamate alle routine 
standard di ogni libreria Open, dose , Espunge e la funzione a 
uso riservato ExtFunct. Ci saranno anche i vettori di BeginlO e 
AbortlO. La routine BeginlO viene chiamata passandogli come 
argomento il puntatore a una struttura IORequest, nella quale il 
programmatore ha memorizzato informazioni sul device che 
deve essere utilizzato e i comandi che questi ha bisogno per 
funzionare. Questi ultimi potrebbero essere comandi standard 
come Open, Read, Write o Close, oppure potrebbero essere dei 
comandi caratteristici del device in questione come il comando 
per allocare un canale audio per l'audio.device. La maggior 
parte dei device conterrà nella jump table anche i vettori per 
una serie di routine che controllano le caratteristiche particolari 
dell’hardware legato al device in questione. 

Tutto questo viene gestito automaticamente dal software di si¬ 
stema e il programmatore deve solo preoccuparsi di preparare 
e spedire l'appropriata struttura di tipo IORequest. 

Quando un task ha finito di lavorare con i dati contenuti nel 
suo buffer in memoria e spedisce la richiesta che questi dati 
vengano salvati su disco, questi verranno trasferiti dal buffer 
del task al buffer del device e attraverso quest’ultimo verranno 
spediti direttamente all’hardware. 

Perché? 

Le librerie e i device fanno un ottimo uso della memoria. Il co¬ 
dice può essere posizionato ovunque nella memoria e le liste di 
sistema manterranno il tutto unito e disponibile. In questo mo- 

Ogni device è collegato a delle strutture chiamate Unii (unità). 

do è facile aggiornare il sistema operativo, perché, dal momen¬ 
to che le librerie e i device sono gestiti dalle jump table. 

struct Unit { 

struct MsgPort unit MsgPort; 

UBYTE unit_flags; 

UBYTE unit_pad; 

UWORD unit OpenCnt; 

}; 

modificare i vettori in queste ultime per puntare a nuove routi¬ 
ne non crea alcun problema al software applicativo. 

L’ordine dei vettori in queste tabelle rimane costante nel tempo 
e un vettore specifico viene rintracciato tramite indirizzamento 
indiretto. Il sistema rintraccia una routine grazie al suo nome, 
utilizzando uno dei linguaggi ad alto livello, in modo che non 

Il trackdisk.device costituisce un esempio lampante, dal mo¬ 
mento che possiamo avere più drive controllati da un unico de¬ 
vice. In questo caso ci sarà una struttura unità per ciascuno dei 
drive utilizzati. Questa unità, comunque, non è un concetto 
hardware. E una struttura software che pennette di passare 
messaggi e dati da e per il task o processo che accede all’unità 
logica. Ogni device dispone di almeno una struttura unit asso¬ 
ciata con esso. 

sia più necessario memorizzare liste di locazioni come succe¬ 
deva nella vecchie macchine a indirizzamento assoluto. 

L'uso di librerie e device è particolarmente importante in un 
computer multitasking. Una volta che uno di questi è stato cari¬ 
cato in memoria, può essere utilizzato da tutti i task in esecu¬ 
zione. Ogni singolo programma può avere delle dimensioni 
assai ridotte perché non ha bisogno di contenere tutte le funzio¬ 
ni, che gli vengono invece messe a disposizione dalla libreria o 

Dal momento che il compito principale di ogni device consiste 
nel gestire l’input e l’output di dati, è necessaria una buona 
comprensione dell’I/O per capirne il funzionamento. 

dal device. E infine, è molto più semplice scrivere un program¬ 
ma quando queste routine di frequente utilizzo sono già state 
scritte per noi. 
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Amiga Structure Browser 


Visita guidata attraverso il sistema 


di Chris Zamara e Nick Sullivan 

Con l'aiuto di questo programma e delle informazioni contenu¬ 
te in questo articolo riusciremo a ottenere delle informazioni 
preziose sul funzionamento di Amiga che non riuscivamo a 
trovare sui manuali. Questa conoscenza ci permetterà di mi¬ 
gliorare la nostra attività di programmazione e di renderla qua¬ 
si sicuramente più proficua di quanto lo sarebbe stata 
altrimenti. 

Con tutti i soldi che guadagnerete da questo incremento pro¬ 
duttivo, potrete comperare l’hardware più costoso e quindi mi¬ 
gliorare ulteriormente le vostre capacità. Questo vi renderà 
programmatori di successo e questo successo aumenterà la 
confidenza in voi stessi. La gente si rivolgerà a voi per avere 
consigli e così aiuterete molti altri che vorrebbero essere così 
bravi e così di successo come voi. Nell’aiutare queste persone, 
non solo ne ricaverete una personale profonda soddisfazione, 
ma diventerete anche famosi e benvoluti, cosa che certo non 
danneggerà la vostra vita sessuale. Dal momento che così tante 
persone vi prenderanno come punto di riferimento e seguiran¬ 
no i vostri consigli, vi troverete a poter disporre di un conside¬ 
revole potere nell’industria dei computer e nelle vostre 
contrattazioni di affari in generale. Nel sentirvi soddisfatti di 
voi stessi, godrete sicuramente di una forma fisica migliore e 
vivrete sicuramente più a lungo, magari fino a più di trecento 
anni! 

In breve, leggere questo articolo e usare il programma relativo 
vi porterà sapienza, potere, successo e prosperità. Migliorerà la 
vostra vita sessuale e vi darà una maggiore stima di voi stessi e 
la sensazione di essere utili. Potrete comperare i computer più 
costosi e le macchine più veloci, se lo desiderate. Vivrete più a 
lungo. Ma la scelta è vostra: leggere questo articolo e realizza¬ 
re questi cambiamenti nella vostra vita o saltare più avanti e ri¬ 
nunciare a realizzare gli enormi potenziali che sapete di 
possedere. 

Beh, magari non otterrete tutte queste cose, ma se volete saper¬ 
ne di più sulle strutture interne di Amiga, o se volete un mezzo 
facile per arrivare ai dati vitali di un programma mentre questo 
è in esecuzione, farete buon uso dello Structure Browser di 
Transactor. 

Sappiamo bene che le varie strutture di sistema sono molto im¬ 


portanti, dal momento che rappresentano la chiave per accede¬ 
re a tutte le entità conosciute dal sistema, come i task, gli scre- 
en, le window, i gadget e tutto il resto. Su Amiga non esistono 
locazioni di memoria fisse, quindi le strutture sono l'equivalen¬ 
te della mappa di memoria che trovavamo sulle macchine non 
multitasking. 

La struttura è un costrutto del linguaggio C, ma possiamo par¬ 
lare della definizione di una struttura dati indipendentemente 
da qualsiasi linguaggio. Una struttura è semplicemente un mo¬ 
do particolare usato per raggruppare alcuni dati. Una struttura 
chiamata ’X’, per esempio, potrebbe essere definita come con¬ 
tenente una word (16 bit), seguita da un puntatore a un’altra 
struttura ’X’ (32 bit), seguito da un puntatore alla struttura ’Y’ 
(32 bit), seguito da una longword (32 bit). Conoscendo la defi¬ 
nizione di una struttura e la sua posizione in memoria è molto 
semplice per il sistema operativo o per il programma applicati¬ 
vo raggiungere le informazioni desiderate. 

Che tipo di informazioni possiamo trovare nelle varie strutture 
del sistema operativo? Ebbene, si possono scoprire alcune cose 
interessanti, per esempio, nelle strutture controllate da Intui- 
tion. Con il programma SB saremo in grado di esaminare, fra 
le altre, le strutture Screen, Window e Gadget. Da queste si 
possono ricavare informazioni su qualsiasi altro programma at¬ 
tivo nel sistema, in quanto gli screen, le window e i gadget di 
ognuno sono collegati come in una specie di rete, dove posso¬ 
no essere raggiunti attraverso l’utilizzo di puntatori contenuti 
nelle altre strutture Screen, Window e Gadget. 

Un puntatore alla prima struttura Screen è tutto quello che ser¬ 
ve per trovare tutto il resto. Questo puntatore può essere rin¬ 
tracciato nella struttura "IntuitionBase", che, a sua volta, viene 
fornita quando la libreria di Intuition viene aperta in seguito al¬ 
la chiamata della funzione OpenLibraryO (la funzione OpenLi- 
brary() è contenuta nella libreria dell’Exec, il cui puntatore si 
trova alla locazione assoluta 000004. l’unica locazione fissa 
nell’intera mappa di memoria di Amiga. Il codice di startup di 
un programma C apre automaticamente la libreria dell’Exec). 
Tutti i programmi che usano Intuition memorizzano le loro in¬ 
formazioni in queste strutture, così attraverso di esse possiamo 
apprendere i particolari di praticamente tutti i programmi che 
sono attualmente nel sistema. 
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Una struttura Screen contiene tutto quello che Intuition ha bi¬ 
sogno di sapere di uno screen, come le sue dimensioni, il titolo, 
il numero di bit piane, il puntatore ai gadget associati a questo 
screen, i flag che descrivono di che tipo di screen si tratti, i co¬ 
lori nei quali deve essere visualizzato, ecc. La struttura Screen 
contiene anche un puntatore alla struttura Window che appar¬ 
tiene alla prima window aperta su quello screen. Una struttura 
Window contiene un puntatore che può indirizzare un’altra 
struttura Window, così tutte le window di uno screen risultano 
collegate insieme. Se ci sono più screen presenti nel sistema 
(se non sta girando un programma applicativo che apre il pro¬ 
prio schermo, l’unico screen normalmente presente è quello 
aperto dal Workbench), ci sarà un puntatore, contenuto nella 
prima struttura Screen, che indirizzerà la struttura Screen suc¬ 
cessiva e così via. In questa maniera possono essere collegati 
insieme un qualsiasi numero di screen. 

In una struttura Window troveremo le solite informazioni ri¬ 
guardanti le dimensioni e il colore, insieme alla variabile 
IDCMPFlags che descrive quali messaggi Intuition sta riceven¬ 
do da quella finestra. La struttura Window contiene anche un 
puntatore al primo di una serie di gadget. Una struttura Gadget 
descrive completamente un gadget (un mezzo estremamente 
semplice per ottenere un input dall’utente per mezzo del mouse 
ed eventualmente della tastiera), la sua posizione, le dimensio¬ 
ni, il tipo, la grafica, ecc. La struttura Gadget viene preparata 
dal programma applicativo prima di essere consegnata a Intui- 
tion, così i valori in essa contenuti rappresentano quelli che il 
programmatore ha inserito nel suo codice. In parole semplici, 
dare un’occhiata alle strutture Gadget di un programma può 
fornire qualche indizio su come è stato scritto il programma 
stesso. 

Altre strutture estremamente interessanti, che però non sono 
state ancora implementate nella versone 1.0 di Structure Brow¬ 
ser sono: Menu, Image, Requester, View, ViewPort, Layer, In- 
terrupt, MemChunk, Message, Task, VSprite, AnimOb (molte 
di queste strutture, come la Task e la Interrupt, sono difficili da 
osservare, poiché i dati che contengono cambiano continua- 
mente). 

La chiave per trovare la locazione in memoria di qualsiasi 
struttura è la struttura Library. Qualsiasi libreria di sistema 
("graphics.library", "intuition.library", "layers.library" per no¬ 
minarne solo alcune) possiede una tale struttura, il cui indirizzo 
è conosciuto come 'base della libreria’, che al suo interno con¬ 
tiene puntatori alle varie strutture che riguardano le funzioni di 
quella libreria. Come abbiamo detto precedentemente, le strut¬ 
ture formano una specie di rete, poiché possiamo raggiungere 
qualsiasi struttura attraverso puntatori contenuti in altre struttu¬ 
re. In questa rete possono essere rintracciati praticamente tutti i 
dati che risultano di una qualche importanza ai fini del funzio¬ 
namento del sistema operativo. In sostanza possiamo ricavare 
uno spaccato dello stato generale del sistema in un qualsiasi 
momento. Se conosciamo le definizioni delle strutture di siste¬ 
ma (ce ne sono più di cento) possiamo vagare e scoprire qual¬ 
siasi cosa che il sistema conosce e in Amiga il sistema 
operativo è molto informato, perché il software applicativo de¬ 
ve passare attraverso il sistema per quasi qualsiasi cosa intenda 
fare. 


Il programma Structure Browser 

Il programma SB rende facile andare a curiosare attraverso 
molte delle strutture di sistema. Si comincia con una lista delle 
librerie disponibili. Nella versione attuale è stata implementata 
solo quella di Intuition. Per visualizzare il contenuto della sua 
struttura Library, basta muovere il mouse sul nome e premere 
il tasto sinistro. La struttura della libreria di Intuition, chiamata 
IntuitionBase, verrà immediatamente visualizzata, completa di 
tutti i nomi dei suoi membri (così come sono definiti nei file 
header standard) e del loro tipo. Nel caso di IntuitionBase, i 
membri sono costituiti da strutture e da puntatori a strutture. 
Per investigare ulteriormente su una qualsiasi di queste struttu¬ 
re è sufficiente usare il mouse come spiegato prima. Il procedi¬ 
mento può essere ripetuto nella nuova struttura e così via, fino 
a quando ce ne sia almeno un’altra disponibile. 

Si può sempre ritornare nella struttura dalla quale proveniamo, 
selezionando il gadget "torna indietro", situato nell’angolo iri 
basso a sinistra della window. Si possono inseguire i propri 
passi a ritroso come si desidera, dal momento che il program¬ 
ma lavora in maniera ricorsiva (il livello di profondità raggiun¬ 
to è visualizzato nell’intestazione della finestra). Le strutture 
che contengono più membri di quanti la finestra del program¬ 
ma possa ospitare verranno divise in pagine di 16 linee e appa¬ 
rirà il gadget "ancora". Possiamo spostarci, quindi, alla pagina 
successiva usando il gadget "ancora" e alla pagina precedente 
usando il gadget "pagina preced". 

Nell’andare di struttura in struttura è facile apprendere alcune 
infonnazioni sui programmi che non si sarebbero potute cono¬ 
scere altrimenti. Per esempio, che tipo di gadget vengono uti¬ 
lizzati in quel bel programma commerciale? Sono veramente 
dei gadget? Il programmatore ha usato un requester o una fine¬ 
stra per visualizzare quel messaggio? Con il semplice uso del 
mouse e di SB possiamo scoprire questo e altro! 

La classe (il tipo di dato) di ogni membro di una struttura viene 
visualizzata traendola direttamente dalla sua dichiarazione nei 
file header del C (il file header appropriato deve essere compi¬ 
lato, utilizzando il comando #include, insieme a ogni program¬ 
ma che intenda accedere a una certa struttura di sistema). 
Queste classi sono standard su Amiga, in quanto vengono di¬ 
chiarate utilizzando il comando typedef all’interno del file 
"exec/ types.h". I tipi fondamentali sono: 

BYTE - 8 bit con segno (char) 

UBYTE - 8 bit senza segno (unsigned char) 
SHORT - 16 bit con segno (short) 

USHORT - 16 bit senza segno (unsigned short) 
LONG - 32 bit con segno (long) 

ULONG - 32 bit senza segno (unsigned long) 

I puntatori ai tipi sopraelencati sono contraddistinti, seguendo 
la sintassi standard del C, con un asterisco (*). Per esempio, un 
puntatore al tipo SHORT viene scritto SHORT *. La sintassi 
del C viene seguita anche per i membri che rappresentano pun¬ 
tatori ad altre strutture. Il puntatore a una struttura di tipo Win¬ 
dow, per esempio, viene denotato da ’struct Window Se un 
membro di una struttura è a sua volta una struttura, non un 
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puntatore a essa, viene denotato senza asterisco. SB, in questo 
caso, non stampa alcun indirizzo per tale membro, dal momen¬ 
to che è contenuto all’interno della struttura attualmente sotto 
esame, della quale si conosce già l’indirizzo. 

I membri di una struttura che non siano puntatori ad altre strut¬ 
ture ma dati reali che possono risultare interessanti, vengono 
visualizzati in modi differenti, a seconda della loro natura. 
Questi dati possono essere semplici numeri, come quelli che 
forniscono i parametri LeftEdge, TopEdge, Width e Height di 
una finestra. L’elemento interessante potrebbe essere un byte, 
una word o una longword contenente dei flag di qualche sorta, 
come quelli indicanti il tipo di una finestra o di un gadget. Op¬ 
pure, i dati che suscitano il nostro interesse potrebbero sempli¬ 
cemente consistere in un’area di memoria contenete una tabella 
di qualche genere o descrivente un’immagine grafica. 

I semplici dati, come LeftEdge ecc., sono stampati in nero nel¬ 
la finestra di SB. Questi membri non possono essere usati per 
accedere ad alcuna informazione supplementare, quindi nulla 
succederà se tentiamo di selezionarli con il mouse. Essi sono 
semplicemente quello che sembrano: un numero e basta. I va¬ 
lori stampati in nero rappresentano spesso proprio quello che 
volevamo sapere di una certa struttura. Quando uno di questi 
valori viene utilizzato per memorizzare dei flag, viene trattato 
diversamente e quindi viene stampato in bianco. Possiamo in¬ 
fatti selezionarlo per avere l’elenco dei flag attivati. Un esem¬ 
pio può essere costituito da una window di tipo "smart 
refresh", fornita di sizing, dose e drag gadget. Il membro 
"Flags" di una tale struttura Window, quando selezionato, vi¬ 
sualizzerà: 

WINDOWDRAG WINDOWSIZING 

WINDOWCLOSE SMART_REFRESH 

(come i nomi dei membri di una struttura, anche i nomi dei flag 
sono definiti nei file header standard usati per lo sviluppo di 
programmi C o Assembly). 

Un’altra forma di output particolare di SB è la stampa esadeci- 
male. Quando il membro di una struttura è un array di valori o 
il puntatore a un’area di memoria rappresentante un bit-piane o 
i dati di un’immagine, possiamo ottenere una stampa esadeci- 
male selezionandone il nome come al solito. Il tipo di dati in 
questione, se presente nella definizione, viene tenuto in consi¬ 
derazione durante la stampa e quindi i dati vengono suddivisi 
in gruppi di byte, word o longword per la visualizzazione. 

Un giro di prova 

Sulla carta il funzionamento di SB potrebbe suonare abbastan¬ 
za complesso, ma in realtà il suo uso è molto semplice. Vedia¬ 
mo un esempio di come potere scoprire il tipo dei gadget 
utilizzati da un programma attualmente in esecuzione. Provia¬ 
mo a usare come esempio lo stesso programma Structure 
Browser. Cercheremo di identificare la costituzione del gadget 
"toma indietro". 

Per prima cosa lanciamo SB. Questo non è difficile: basta digi¬ 
tare ’sb’ nel CLI (o ’run sb’ se vogliamo potere disporre ancora 


del CLI mentre SB sta girando). Apparirà la finestra di SB, leg¬ 
germente spostata verso il basso, in modo da lasciare visibile 
un pezzetto dello screen del Workbench. Ci verrà chiesto di se¬ 
lezionare la struttura di una libreria. Dal momento che in que¬ 
sta versione del programma ne è disponibile una sola, la scelta 
non risulta difficile. Selezioniamo "Intuition" puntandola con il 
mouse e premendo il tasto sinistro. Dopo questa operazione, 
verrà visualizzato il contenuto della struttura "IntuitionBase", 
ogni membro con il relativo tipo e valore visualizzati sulla de¬ 
stra. Tutti i membri consistono di una struttura o di un puntato¬ 
re a essa. I primi due membri sono messi fra parentesi per 
segnalare il fatto che non sono ancora disponibili per un ulte¬ 
riore approfondimento in questa versione del programma. Allo 
scopo di mantenere le dimensioni del listato di SB ragionevoli 
per la pubblicazione su queste pagine, abbiamo implementato 
solo alcune fra le strutture più importanti. I riferimenti a tipi di 
dati non implementati vengono messi fra parentesi e la loro se¬ 
lezione non produce alcun effetto. 

Continuiamo nel nostro viaggio per raggiungere il gadget in 
questione. Siccome il programma al quale siamo interessati ha 
una window sullo schermo del Workbench, dobbiamo prima 
raggiungere la struttura di quest’ultimo. Dal momento che lo 
schermo attivo in questo momento, quello nel quale stiamo la¬ 
vorando, è proprio quello del Workbench, possiamo recarci lì 
selezionando il membro "ActiveScreen" della struttura Intui- 
tionBase. Basta la pressione del tasto sinistro del mouse ed ec¬ 
co apparire la prima pagina di informazioni sulla struttura 
Screen del Workbench. Possiamo verificare di avere raggiunto 

10 screen desiderato esaminando il membro chiamato "Title". 
Alla sua destra dovrebbe comparire "Workbench Screen". Per 
vedere gli altri membri della struttura Screen basta selezionare 

11 gadget "ancora" che è apparso nella zona bassa della finestra. 
Il gadget "pagina preced" ci farà tornare alla pagina preceden¬ 
te. Il secondo membro della struttura Screen si chiama "Fir- 
stWindow" e punta alla prima struttura Window nella lista che 
contiene tutte le window di questo screen. 

Selezionando "FirstWindow" verrà visualizzata una struttura 
Window. Molto probabilmente questa è la finestra che stavamo 
cercando, la finestra di SB. Il membro "Title" ci dirà quale fi¬ 
nestra stiamo esaminando perché riporta fedelmente quello che 
appare nella barra riservata al titolo della medesima. Se la fine¬ 
stra non è quella che cercavamo, possiamo esaminare quella 
successiva selezionando il primo membro della struttura, chia¬ 
mato "NextWindow". Verrà visualizzata un'altra struttura 
Window, appartenente alla finestra successiva nella catena. 
Fermiamoci quando raggiungiamo la finestra di Structure 
Browser (lo possiamo verificare da "Title"). Possiamo notare 
altri elementi interessanti in questa struttura, quali le dimensio¬ 
ni e i flag. Proviamo a selezionare il membro "Flags" per ve¬ 
derne il contenuto in forma esplicita. Anche se non siamo 
molto familiari con la programmazione di Intuition, i nomi dei 
flag ci possono suggerire il loro significato. 

Adesso che abbiamo trovato la struttura Window che cercava¬ 
mo, vediamo di trovare il puntatore alla lista di gadget relativa 
a questa finestra. Non c’è nulla del genere nella prima pagina, 
quindi selezioniamo il gadget "ancora" per vedere gli altri 
membri. All’incirca a metà della seconda pagina troviamo il 
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membro chiamato "FirstGadget" il quale punta a una struttura 
Gadget (il suo tipo è ’struct Gadget che significa 'puntatore 
a struttura Gadget’). Selezioniamolo, ed ecco apparire la prima 
di una serie di strutture Gadget. Esaminando le variabili Lef- 
tEdge e TopEdge possiamo risalire alla posizione del gadget 
nella finestra. Per raggiungere il prossimo gadget nella lista è 
sufficiente selezionare il primo membro della struttura, chia¬ 
mato "NextGadget Possiamo scorrere tutta la lista dei gadget 
in questo modo, fermandoci quando vogliamo esaminare le va¬ 
riabili "Flags", "Activation" o "GadgetType”. Quest’ultima ci 
rivelerà se il gadget sia di tipo BOOLGADGET (booleano), 
PROPGADGET (proporzionale) o STRGADGET (stringa). 

Prima o poi raggiungeremo un gadget con TopEdge di -12 e 
LeftEdge di 10. Dal momento che il flag GRELBOTTOM è 
settato nella variabile "Flags", sappiamo che il valore TopEdge 
indica che il bordo superiore del gadget dista di 12 pixel dal 
bordo inferiore della finestra. Questo allora è il gadget "torna 
indietro" che stavamo cercando e ciò ci viene confermato esa¬ 
minando il membro "GadgetText" della struttura gadget. Pos¬ 
siamo vedere esattamente come è stata preparata questa 
struttura Gadget nel programma Structure Browser (usare gli 
stessi dati dell’immagine di un gadget contenuto in un altro 
programma per crearne uno analogo all'interno di un nostro 
programma, potrebbe essere considerato una violazione del co¬ 
pyright. La versione attuale di SB non supporta l'esplorazione 
delle strutture "Image", quindi è inutile fare qui raccomanda¬ 
zioni del tipo "Non fatelo a casa, bambini!"). 

Il programma SB non supporta tutte le strutture di sistema, al¬ 
trimenti riempirebbe l’intera rivista. A benefìcio di coloro che 
ordineranno il disco di Transactor, abbiamo accluso, oltre alla 
versione 1.0 pubblicata in queste pagine, la versione 1.3 che ne 
incorpora qualcun’altra. Il programma, comunque, è progettato 
in modo che risulti abbastanza facile aggiungere le strutture di 
nostro gradimento, partendo dai file "include" che si trovano 
sul disco di sviluppo del C e sul ROM Kernel Manual. Tratte¬ 
remo di questo più approfonditamente nel seguito dell’articolo. 
SB è un programma di pubblico dominio, quindi siete liberi di 
usarlo e modificarlo a piacere. 

Applicazioni di SB 

A questo punto vi sarete resi conto che SB rappresenta un 
grande aiuto per apprendere la costituzione delle strutture in¬ 
terne di Amiga. Ma ci sono alcune altre buone ragioni per tene¬ 
re SB nei dischi che usiamo maggiormente, magari nella 
directory C del disco Workbench. 

Per prima cosa, SB costituisce un comodo mezzo per ottenere 
la definizione di una struttura. E più facile lanciare SB e sele¬ 
zionare una struttura per averne la definizione, piuttosto che 
andare a sfogliare il ROM Kernel Manual. E se non possedia¬ 
mo questo manuale, è sicuramente più facile che cercare la de¬ 
finizione in mezzo a così tanti file include. Se poi non abbiamo 
neanche questi ultimi, allora è proprio l’unico mezzo a disposi¬ 
zione! 

SB può essere usato anche come strumento di debugging. Se il 
nostro programma si comporta stranamente, possiamo dare 


un’occhiata a come Intuition vede le nostre finestre, i nostri 
gadget, per essere sicuri che siano tutti correttamente iniziàliz- 
zati e collegati l’uno con l’altro, proprio come intendevamo 
che fossero. Possiamo fare un giro esplorativo in qualsiasi mo¬ 
mento dell’esecuzione del nostro programma, per vedere quali 
sono gli effetti prodotti da una certa azione intrapresa. Una 
specie di strumento di trace, insomma, ma che riguarda solo 
l’interazione del programma con il sistema operativo. 

Un altro beneficio offerto da SB consiste nel potere imparare le 
tecniche di programmazione utilizzate dagli altri programmi, 
nel preparare le loro strutture, per ottenere un determinato ef¬ 
fetto. Nell’investigare in merito a entità conosciute del sistema 
operativo, possiamo vedere quali effetti hanno sul loro com¬ 
portamento il cambiamento di certi flag e di certe variabili. Se 
siamo curiosi di conoscere quali i trucchi stia utilizzando un 
programma che abbiamo appena lanciato, basta dare un’oc¬ 
chiata alle sue strutture. Per esempio, lo sapevate che il Wor¬ 
kbench utilizza una window BORDERLESS e BACKDROP 
che si trova sullo schermo del Workbench appena sotto la barra 
che contiene il nome dello schermo? Noi non lo sapevamo, fi¬ 
no a quando non lo abbiamo scoperto curiosando con SB. Si 
possono trarre delle buone idee esaminando l’uso che gli altri 
fanno delle risorse messe a disposizione da Intuition. 

Versioni future di SB 

Il programma può essere espanso a piacere e può crescere no¬ 
tevolmente di dimensioni, ma ne varrebbe la pena per avere 
una visione completa del funzionamento interno di Amiga. Ol¬ 
tre all’implementazione di tutte le strutture mancanti nella ver¬ 
sione 1.0 e nella 1.3, si potrebbe migliorare notevolmente il 
modo in cui vengono gestiti i dati di basso livello. I dati grafi¬ 
ci, per esempio, potrebbero essere trasformati nelle relative im¬ 
magini, anziché visualizzarli come stampa esadecimale. Alcuni 
valori, come le coordinate del mouse che si trovano nella strut¬ 
tura Window (MouseY e MouseX) potrebbero essere aggiorna¬ 
te continuamente, per dame una lettura in tempo reale. Le 
stampe esadecimali potrebbero essere affiancate dall’equiva¬ 
lente ASCII. I dati delle immagini e dei BitMap dovrebbero 
poter essere salvati su disco in formato IFF. Potrebbe esserci 
un’opzione per salvare su disco il contenuto di una qualsiasi 
struttura in linguaggio C o Assembly, per poterla poi riutilizza¬ 
re nei nostri programmi e via di questo passo. Se qualcuno ha 
qualche idea valida, la implementi! Non vogliamo tenerci tutto 
il merito e la gloria! (leggi: non vogliamo fare tutto il lavoro da 
soli!) 

Note al listato 

Il sorgente di SB è diviso in vari file, ognuno con uno scopo 
ben specifico. Il cuore del programma e le sue funzioni princi¬ 
pali sono contenute nel file "sb.c". Le chiamate a Intuition e 
tutte le funzioni che gestiscono l’interfaccia con l’utente si tro¬ 
vano nel file "sbio.c". Gli altri file contengono le routine che 
gestiscono i vari tipi di strutture. 1 file "sbWindow.c", "sbScre- 
en.c", "sbGadget.c" e "sbNode.c" contengono le routine per ge¬ 
stire le strutture implicate nel loro nome. "sbGraphics.c" 
gestisce le strutture RastPort e BitMap relative alla "gra¬ 
phics.library”. Il file "sb.h" contiene svariati #define e la defi- 
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nizione della struttura StructData. I file possono essere compi¬ 
lati utilizzando indifferentemente il compilatore della Manx o 
quello della Lattice. 

Nel digitare i listati riportati di seguito, bisogna prestare parti¬ 
colare attenzione all’array ’structdata’ che troviamo in ogni 
funzione di stampa delle strutture. Il primo carattere del nome 
di ogni membro è costituito da uno spazio, oppure da un meno, 
oppure da una parentesi tonda aperta. È importante usare quel¬ 
lo giusto. Inoltre, è critico anche l’uso della costante che indica 
le dimensioni dei dati trattati, in quanto se viene usata quella 
sbagliata (esempio, INTSIZE al posto di PTRSIZE) otterremo 
dei risultati sbagliati, se non addirittura una visita del guru. 

Note al programma 

SB è già utile così com’è, ma alcuni vorranno modificarlo per 
aggiungere strutture alle quali sono particolarmente interessati. 
Ecco quindi, per facilitare questa operazione, una spiegazione 
sul funzionamento del programma. 

Il principio che governa SB è molto semplice. Esiste una fun¬ 
zione specializzata per ogni tipo di struttura contemplata. Se 
una struttura contiene più membri di quanti ne siano visualiz¬ 
zabili sullo schermo contemporaneamente, ci sarà un’altra fun¬ 
zione per ciascuna delle pagine successive. Alla funzione viene 
passato un puntatore alla struttura in esame (e un offset, nel ca¬ 
so delle funzioni che riguardano le pagine successive) e questa 
ne stampa i nomi dei membri, i tipi e i valori, quindi attende un 
input. A seconda del membro selezionato dall’utente, un’appo¬ 
sita routine viene chiamata per stampare quel membro della 
struttura e quindi si attende nuovamente un input. Potrebbe 
darsi il caso in cui una routine chiama sé stessa, come succede 
nel passare attraverso una catena di strutture Gadget, per esem¬ 
pio. 

In ogni caso, qualsiasi selezione effettuata porta il programma 
a un livello più in basso e l’unico modo che l’utente ha di ritor¬ 
nare verso l’alto è quello di selezionare il gadget "toma indie¬ 
tro" o "pagina preced", causando l’uscita dall’ultima funzione 
chiamata (dal momento che ogni livello che visitiamo rappre¬ 
senta un livello in più nella nidificazione delle chiamate alle 
funzioni, c’è la possibilità che lo stack vada in overflow se si 
scende tropppo in basso. Abbiamo calcolato, tuttavia, che an¬ 
che con il limitato stack di sistema di 4000 byte, bisognerebbe 
andare oltre 100 livelli più in basso per correre questo rischio). 

Oltre alle funzioni specifiche per ogni struttura, ci sono le fun¬ 
zioni per gestire l’output esadecimale e la stampa esplicita dei 
flag. Queste sono contenute nel file "sb.c". In questo file tro¬ 
viamo anche la funzione put(), utilizzata per comunicare alla 
funzione di output in "sbio.c" che tipo di dati stampare. Questa 
viene chiamata da tutte le funzioni di output e le viene passato 
un puntatore alla struttura e un puntatore a un array di strutture 
StructData. La modifica di questo array è la chiave che permet¬ 
te di implementare nuove strutture in SB. 

La struttura StructData, definita in "sb.h", contiene tutte le in¬ 
formazioni a proposito del membro di una struttura: il nome, il 
tipo, le modalità di stampa e le dimensioni. Il nome e il tipo so¬ 


no semplicemente dei puntatori a stringhe da stampare. Le mo¬ 
dalità di stampa sono necessarie per sapere come stampare i 
valori di quel membro: come byte, short o long, con o senza 
segno, o come una stringa o come un puntatore. Riferitevi alla 
funzione put() per sapere esattamente come viene inteipretato 
questo argomento. L’ultimo membro della struttura StructData, 
la dimensione, indica il numero di byte utilizzati dal membro 
sotto esame. Le costanti BYTESIZE, INTSIZE e PTRSIZE, 
definite in "sb.h", specificano le dimensioni di 1, 2, e 4 byte. 
Quando il membro in esame è una struttura (e non un puntatore 
a essa), si utilizza la macro SZ, definita in "sb.h", per calcolar¬ 
ne le dimensioni. Ad esempio, SZ(View) anziché sizeof(struct 
View). 

Prendendo spunto dalle funzioni PrWindow(), PrScreen() e 
PrGadget() non dovrebbe essere difficile aggiungere le altre. 
Quando implementiamo una nuova struttura, dobbiamo toglie¬ 
re le parentesi dal suo nome per permettere all’utente di sele¬ 
zionarla. Una parentesi tonda aperta come primo carattere del 
nome di un membro fa in modo che l’utente non possa selezio¬ 
narlo (ne impedisce la trasformazione in gadget). Per renderne 
possibile l’esplorazione, basta togliere queste parentesi da tutte 
le strutture che contengono un puntatore alla nuova struttura 
appena implementata e aggiungere una chiamata alla nostra 
nuova funzione nel corpo dell’istruzione SWITCH. 

In ogni funzione di stampa che implementiamo, dovremo pre¬ 
parare un array statico di strutture StructData, così come avvie¬ 
ne nelle altre funzioni. I nomi dei membri devono iniziare con 
uno spazio nel caso di flag, array o puntatori a strutture che SB 
è in grado di gestire, con un meno (-) per semplici elementi di 
dati che devono essere visualizzati in nero e che non saranno 
selezionabili, oppure con una parentesi per i puntatori a struttu¬ 
re non ancora implementate. 

La stampa del tutto e l’attesa di input dall’utente vengono ge¬ 
stite dalla funzione GetChoice(). I membri che l’utente può se¬ 
lezionare sono implementati come gadget privi di qualsiasi 
immagine o bordo. Un array di 16 strutture IntuiText è predi¬ 
sposto per ricevere il testo di ogni linea che deve essere stam¬ 
pata nella finestra. Viene preparato anche un array di 16 gadget 
di tipo booleano, ognuno dei quali punta a una diversa struttura 
IntuiText. Ci sono anche le strutture relative ai gadget "torna 
indietro" (che viene anche usato per "pagina preced") e "anco¬ 
ra". 

Quando GetChoice() viene chiamata, essa chiama a sua volta 
RedisplayO per preparare i nomi dei membri della struttura e 
per costruire la necessaria lista di gadget. RedisplayO rimuove 
per prima cosa tutti i gadget esistenti eccetto il primo nella li¬ 
sta, il gadget "toma indietro". Esegue poi un loop tante volte 
quante sono le linee da stampare (massimo 16) per aggiornare 
il contenuto di IntuiText o per aggiungere un gadget alla lista. 
Dopo il loop viene aggiunto il gadget "ancora" (qualora ce ne 
sia bisogno). Infine viene chiamata la funzione di Intuition Re- 
freshGadgets() per visualizzare il tutto nella finestra di SB. 

Dopo che RedisplayO ha finito il suo lavoro, GetChoice() at¬ 
tende un evento IDCMP che segnala l’avvenuta selezione di un 
gadget da parte dell’utente. Se la finestra è stata chiusa, verrà 
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chiamata la funzione CloseOut() per ripulire tutto e chiudere le 
librerie prima di uscire. Se è stato selezionato un altro gadget, 
invece, la sua identità viene restituita alla funzione che ha chia¬ 
mato GetChoiceQ. I numeri di identità dei gadget associati ai 
membri di una struttura sono costituiti dal loro numero sequen¬ 
ziale - 1 per il primo e così via. Il gadget "pagina preced" ha ID 
= 0, mentre "ancora" ha come ID la costante MOREGAD, de¬ 
finita come 25 nel file "sb.h". 


#define FLAGFIELDS 4 

extern struct IntuitionBase *IntuitionBase; 
extern struct IntuiText ChoiceText[], BackIText; 
APTR OpenLibrary (); 

int level = 0; /* current level of nesting */ 
static char textlines[MAXGADG + 1][80]; 
extern void PrlntuiBase(), HexLineO; 

void main() 


Divertitevi con Structure Browser! 


Listato 1: 

/* sb.h */ 

♦include <intuition/intuition.h> 
♦include <intuition/intuitionbase.h> 
♦include <stdio.h> 


int choice = -1; 

SetupGadg(); 

OpenStuffO; /* apre intuition.library & window */ 
while (choice) { 

putHeader("Scegliere una libreria", NULL); 
ChoiceText[0].IText = (UBYTE *)" Intuition 
struct Library"; 

BackIText.IText = (UBYTE *)" fine programma"; 
switch (choice = GetChoice(1)) { 
case 1: 

PrlntuiBase ("struttura IntuitionBase", 
IntuitionBase); 

break; 


CloseOut ( ); 


♦define SZ(x) sizeof(struct x) 

♦define DATASIZE (sizeof(structdata) 
sizeof(struct StructData)) 

♦define PTRSIZE sizeof(APTR) 
sizeof(short) 
sizeof(char) 


♦define INTSIZE 
♦define BYTESIZE 


void PrlntuiBase (string, IBase) char *string; 
struct IntuitionBase *IBase; 

{ 


♦define MAXGADG 16 

static 

struct StructData structdata[] 

= { 


♦define MOREGADG 25 /* ID del gadget "ancora" */ 

( 

"(LibMode", 

"struct 

Library )", 

0 , 



SZ (Library) 

}, 



struct StructData { 

( 

"(ViewLord", 

"struct 

View )", 

0 , 

char *membername; 


SZ(View) 

}, 



char *membertype; 

( 

" ActiveWindow", 

"struct 

Window , 

5, 

int printtype; 


PTRSIZE 

}, 



int datasize; 

{ 

" ActiveScreen", 

"struct 

Screen *", 

5, 

) ; 


PTRSIZE 

i, 




{ 

" FirstScreen", 

"struct 

Screen *", 

5, 


1 ; 

int sum 

PTRSIZE 

} 



Listato 2: 

, choice = -1; 





/*The Transactor Structure Browser (SB) VI. 0 
★ 

*By Nick Sullivan and Chris Zamara (AHA!) (c)1989 

•k 

* Strutture implementate nella V1.0: 

* IntuitionBase, Window, Screen, RastPort, BitMap, 

* Gadget, Node, MsgPort, IntuiText, TextAttr. 

* 

* Il programma può essere distribuito liberamente. 
*/ 


level++; 

while (choice) ( 

sum = SetOptionText(string, structdata, 
(APTR)IBase, DATASIZE, 0); 
switch (choice = GetChoice(DATASIZE)) ( 

case 3: 

if (IBase->ActiveWindow) 

PrWindow("Window attualmente attiva", 
IBase->ActiveWindow); 

break; 
case 4 : 

PrScreen("Screen attualmente attivo", 
IBase->ActiveScreen); 


♦include "sb.h" break; 

♦ define MIN(x,y) ( (x) < (y) ? (x) : (y) ) case 5: 


noi 


‘b 
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I dischi di Fred Fish 


Prima guida ragionata al loro contenuto 


ANIMAZIONE 


53 : 

3D_PYRAMID 

112 

BEACHBIRDS 

100 

BERSERK 

132 

BERSERK 

134 

BOINGTHROWS 

53 

CAMERA 

123 

CAR 

53 

CLOWN 

106 

DEATHSTAR 

125 

ELGATO 

116 

F-15 

112 

FOCUS 

29 

GROW-UR-OWN 

126 

HBHILL 

47 

JUGGLER 

97 

JUGGLER 

116 

KAHNANKAS 

115 

KILLER 

29 

KNIGHT 

106 

LASERS 

73 

LMV 

29 

LUNA 

109 

MACHINE 

115 

MARKETROID 

127 

NEMESIS 

126 

ONLYAMIGA 

112 

RGB 

127 

RIPPLES 

116 

ROCKER 

29 

RUBIK 

29 

SNAPDEMO 

106 

SWING 


1.4 


1.0 

1.0 


COMANDI BATCH 


39 ASK 


46 

CHECKMODEM 

123 

ELSE 

123 

ENDIF 

29 

ENOUGH 

123 

FAILAT 

123 

IF 

32 

INPUT 

123 

LAB 

79 

MOUNTED 

79 

MOUNTED 

49 

QMOUSE 


1.1 


CREA PIRAMIDI COLORATE E LE RUOTA IN 3D - (PLAYER) 

SCENA RAFFIGURANTE UNA SPIAGGIA CON GABBIANI CHE VOLANO 
MONOCICLI CHE RIMBALZANO SU UNA SFERA - (SHOWANIM) 
MONOCICLI CHE RIMBALZANO SU UNA SFERA - (SHOWANIM) 
CIOCATORE CHE FA CANESTRO 
ANIMAZIONE DI UN CAMMELLO CHE CAMMINA 

INCIDENTE AUTOMOBILISTICO - (SHOWANIM) 

CLOWN CHE CHE IMITA UN GIOCOLIERE CONTRE BIRILLI 

ASTRONAVI E MORTE NERA / (DA GUERRE STELLARI) 

GATTO CHE CAMMINA / (RUOTA IN 3D) - (SHOWANIM) 

ANIMAZIONE DI UN F-15 DISEGNATO PER LINEE - (MOVIE) 
FUNZIUONI MATEMATICHE SI DISSOLVONO ... 

ROBOT CREA UN ROBOT FEMMINA - (PLAYER) 


UOMO CHE BALLA / (MODALITÀ' HALF BRITE) 


(SHOWANIM) 


GIOCOLIERE CON TRE SFERE / (RAY-TRACED) 

GIOCOLIERE CON TRE SFERE / (RAY-TRACED) 

SIMULAZIONE DI MOTO PERPETUO / (RAY-TRACED) 

AMIGA CONTRO LE COMPETIZIONI 

CAVALIERE CHE CAVALCA UN CAVALLO - (PLAYER) 

LASER CHE DISEGNA LA SCRITTA QUICKFLIX - (QUICKFLIX) 
JIMMY STEWART / (SEQUENZE TV DIGITALIZZATE) - (LMV) 
ATTERRAGGIO SULLA LUNA - (PLAYER) 

MACCHINA ANIMATA - (SHOWANIM) 

COMMERCIALIZZAZIONE DI AMIGA / (IN FORMA DI DEMO GIOCO) 
STELLE PIANETI E BUCHI NERI / (CON EFFETTI SONORI) 
PIRAMIDE COMPOSTA DA TRE SFERE 

MOSTRA I RISCHI DELLE RADIAZIONI RGB - (PROJECTOR) 
BANDIERA OSSERVATA DA VARI PUNTI DI VISTA - (SHOWANIM) 
ANIMAZIONE CON OMBRE DI UNA SEDIA - (MOVIE) 

CUBO DI RUBIK ANIMATO IN 3D 
MONTA E SMONTA UN PUZZLE - (PLAYER) 

SIMULAZIONE DI MOTO PERPETUO - (QUICKFILX) 


[TUNNELL] 

[SCHWAB] 

[SCHWAB] 

[LANDIS] 

[AEGIS 

DEVELOPMENT] 

[HASTINGS] 

[AEGIS 

DEVELOPMENT] 

[BLAIR- 

SULLIVAN] 

[GRAHAM] 

[HAGEN] 
[AEGIS 

DEVELOPMENT] 

[BLAIR- 

SULLIVAN] 

[GRAHAM] 

[GRAHAM] 

[OFFER] 

[WILT] 

[SACHS] 

[WEBSTER] 

[AEGIS 

DEVELOPMENT] 

[HASTINGS] 

[SCHWAB] 

[RILEY] 

[HANS SINGH] 

[HAGEN] 

[HANSTINGS] 

[GRAHAM] 

[KINNERLEY] 

[AEGIS] 

[QUICKFLIX] 


RICHIEDE UNA RISPOSTA DI UN SINGOLO CARATTERE 
CONTROLLA LA PRESENZA DI UN MODEM 
ARP - SOSTITUISCE IL COMANDO AMIGADOS 
ARP - SOSTITUISCE IL COMANDO AMIGADOS 

TEST PER LA PRESENZE DELLE RISORSE ADEGUATE / (I.E. RAM) [BARRETT] 
ARP - SOSTITUISCE IL COMANDO AMIGADOS 
ARP - SOSTITUISCE IL COMANDO AMIGADOS 
SCRIVE L'INPUT DI UN UTENTE IN UN FILE DELLA RAM 
ARP - SOSTITUSCE IL COMANDO AMIGADOS 

CONTROLLA SE IL DEVICE SPECIFICATO E' STATO MONTATO 
CONTROLLA SE IL DEVICE SPECIFICATO E' STATO MONTATO 
RITORNA IL VALORE DEL PULSANTE SINISTRO DEL MOUSE 


[WILLIAMS] 

[DILLON] 


[BEOGELEIN] 

[NESBITT] 
[DE SILVA] 
[RETHMEYER] 


41 

















□ 


Transactor per AMIGA 


m c 


7 9 QUERYANY 
123 QUIT 
123 SKIP 


2.0 * PERMETTE DI GESTIRE DECISIONI DEL TIPO SI/NO 

ARP - SOSTITUISCE IL COMANDO AMIGADOS 
ARP - SOSTITUISCE IL COMANDO AMIGADOS 


[SMITH] 


COMANDI CLI 


123 

ADDBUFFERS 



ARP - SOSTITUISCE IL COMANDO AMIGADOS 


39 

ALIST 


★ 

SOSTITUISCE IL COMANDO AMIGADOS / (SOLO NOME DEI FILE) 

[WILLIAMS] 

32 

AREACODE 

1.4 


DECODIFICA I PREFISSI DEGLI USA 

[BEOGELEIN] 

40 

AREACODE 

1.5 


DECODIFICA I PREFISSI DEGLI USA 

[BEOGELEIN] 

32 

ASC 

1.1 


RITORNA IL VALORE ASCII DI UN CARATTERE 

[BEOGELEIN] 

52 

ASSIGN 


Ve 

SOSTITUISCE IL COMANDO AMIGADOS 

[MCMANIS] 

32 

BIT 

1.1 


ESEGUE OPERAZIONI LOGICHE COME AND,OR,XOR,EQU S IMP 

[BEOGELEIN] 

123 

BREAK 



ARP - SOSTITUISCE IL COMANDO AMIGADOS 


123 

BREAK 



ARP - SOSTITUISCE IL COMANDO AMIGADOS 


53 

BREAK 

87/01 

★ 

ARP - SOSTITUISCE IL COMANDO AMIGADOS 

[BALLANTYNE] 

123 

CD 



ARP - SOSTITUISCE IL COMANDO AMIGADOS 


53 

CD 

87/01 

Ve 

ARP - SOSTITUISCE IL COMANDO AMIGADOS 

[HEATH] 

123 

CHANGETASKPRI 



ARP - SOSTITUISCE IL COMANDO AMIGADOS 


53 

CHMOD 

87/01 

* 

ARP - CAMBIA LO STATO DI PROTEZIONE DI UN FILE 

[BALLANTYNE] 

32 

CHR 

1.1 


RITORNA IL VALORE ESAD.,BIN.,DEC.,OTT., DI UN VALORE 

[BEOGELEIN] 

39 

CLS 


* 

CANCELLA IL CONTENUTO DELLA FINESTRA CORRENTE 

[WILLIAMS] 

32 

CONV 

1.1 


CONVERSIONI DECIMALI,ESADECIMALI,OTTALI,BINARIE 

[BEOGELEIN] 

75 

COPY 

1.0 

* 

SOSTITUISCE IL COMANDO AMIGADOS / (NON CAMBIA LE DATE) 

[LYDIATT] 

123 

CP 



ARP - SOSTITUISCE IL COMANDO COPY DI AMIGADOS 


123 

DELETE 



ARP - SOSTITUISCE IL COMANDO AMIGADOS 


36 

ECHO 



SOSTITUISCE IL COMANDO ECHO 

[PHILLIPS] 

39 

ECHO 


Ve 

SOSTITUISCE IL COMANDO ECHO / (PERMETTE \N) 

[WILLIAMS] 

79 

ECHO 


Ve 

SOSTITUISCE IL COMANDO ECHO / (PERMETTE ESA.,BIN.,DEC.,) 

[NESBITT] 

123 

ECHO 



ARP - SOSTITUISCE IL COMANDO AMIGADOS 


53 

ECHO 

86/12 

Ve 

ARP - SOSTITUISCE IL COMANDO AMIGADOS 

[HEATH] 

123 

FILENOTE 



ARP - SOSTITUISCE IL COMANDO AMIGADOS 


53 

FILENOTE 

87/01 

Ve 

ARP - SOSTITUISCE IL COMANDO AMIGADOS 

[BALLANTYNE] 

32 

HELP 

1.1 


RITORNA LA SINTASSI DEI COMANDI AMIGADOS/DOSPLUS 

[BEOGELEIN] 

79 

INFO 


Ve 

SOSTITUISCE IL COMANDO AMIGADOS 

[MCMANIS] 

123 

INFO 



ARP - SOSTITUISCE IL COMANDO AMIGADOS 


87 

INSTALL 


Ve 

SOSTITUISCE IL COMANDO AMIGADOS 

[TURNER] 

87 

INSTALL 


Ve 

SOSTITUISCE IL COMANDO AMIGADOS 

[NESBITT] 

123 

JOIN 



ARP - SOSTITUISCE IL COMANDO AMIGADOS 


105 

L 



SOSTITUISCE IL COMANDO AMIGADOS / (MOSTRA FLAG ARCHIVIO) 

[DAVIES] 

123 

MAKEDIR 



ARP - SOSTITUISCE IL COMANDO AMIGADOS 


53 

MAKEDIR 

87/01 

Ve 

ARP - SOSTITUISCE IL COMANDO AMIGADOS 

[HEATH] 

32 

MATH 

1.2 


ESEGUE SOMMME,SOTTRAZIONI,DIVISIONI,MOLTIPLICAZIONI 

[BEOGELEIN] 

38 

NEWSTAT 


Ve 

SOSTITUISCE IL COMANDO AMIGADOS 

[SYNGE] 

123 

PATH 



ARP - SOSTITUISCE IL COMANDO AMIGADOS 


123 

PROMPT 



ARP - SOSTITUISCE IL COMANDO AMIGADOS 


53 

PROMPT 

87/01 

★ 

ARP - SOSTITUISCE IL COMANDO AMIGADOS 

[HEATH] 

123 

PROTECT 



ARP - SOSTITUISCE IL COMANDO AMIGADOS 


123 

RELABEL 



ARP - SOSTITUISCE IL COMANDO AMIGADOS 


123 

RENAME 



ARP - SOSTITUISCE IL COMANDO AMIGADOS 


6 

SETPARALLEL 

1.1 

* 

CAMBIA I PARAMETRI DELLA PORTA PARALLELA DA CLI 

[POHORSKY 






(STOBIE)] 

6 

SETSERIAL 

3.2 

* 

CAMBIA I PARAMETRI DELLA PORTA SERIALE DA CLI 

[POHORSKY 






(STOBIE)] 

123 

SORT 



ARP - SOSTITUISCE IL COMANDO AMIGADOS 


105 

STACK 


Ve 

SOSTITUISCE IL COMANDO AMIGADOS / (IN ASSEMBLER) 

[MCDIARMID] 

123 

STACK 



ARP - SOSTITUISCE IL COMANDO AMIGADOS 


123 

STATUS 



ARP - SOSTITUISCE IL COMANDO AMIGADOS 


123 

TYPE 



ARP - SOSTITUISCE IL COMANDO AMIGADOS 


79 

WHY 

1 

Ve 

SOSTITUISCE IL COMANDO AMIGADOS / (PIU' INFORMAZIONI) 

[NESBITT] 

74 

XCOPY 



SOSTITUISCE IL COMANDO AMIGADOS 

[ROBERTSON] 


COLLEZIONE COMANDI CLI 

79 ASMTOOLS * 5 COMANDI SOSTITUTIVI [NESBITT] 

COMANDI CLI 

32 DOSPLUS1 COMANDI CLI UTILI AI SVILUPPATORI DI SOFTWARE [BEOGELEIN] 

32 DOSPLUS2 COMANDI CLI UTILI AI SVILUPPATORI DI SOFTWARE [BEOGELEIN] 


no 
















□ 


Transactor per AMIGA 


UTILITY CLI 


74 CLED 

1.3 


EDITOR DI LINEA 


[EMPLEO] 

81 

CLED 

1.4 


EDITOR DI LINEA 


[EMPLEO] 

69 

CONMAN 

0.9 

* 

CON:EDITOR DI LINEA, L'HISTORY ECC. 


[HAWES] 

90 

CONMAN 

0.98B 


CON:EDITOR DI LINEA, HISTORY ECC. 


[HAWES] 

81 

CONMAN 

0.99B 


CON:EDITOR DI LINEA, HISTORY ECC. 


[HAWES] 

100 

CONMAN 

1.0 


CON : EDITOR DI LINEA, HISTORY ECC. 


[HAWES] 

133 

CONMAN 

1.1 


CON : EDITOR DI LINEA, HISTORY ECC. 


[HAWES] 

40 

DOSHELP 

1.60 

* 

ASSISTANZA NELL'USO DEI COMANDI AMIGADOS 

[YOUELLS] 

50 

FIRSTSILICON 

8611.2 


PERMETTE DI IMMETTERE I COMANDI AMIGADOS DA UNA FINESTRA 

[GOODEVE] 

75 

HARDCOPY 


* 

PRODUCE L'HARDCOPY DEL CLI CORRENTE 


[CERVONE] 

131 

MACHIE 


k 

PARTE UN CLI IN QUALSIASI MOMENTO 


[ROKICKI] 

71 

PETCLI 



PERMETTE DI EDITARE UNA LINEA CLI - 

(AMIGABASIC) 

[KITTEL] 

35 

POPOLI 

1.0 

k 

PARTE UN CLI IN QUALSIASI MOMENTO / 

(SALVA SCHERMO) 

[TOEBES] 

40 

POPCLI 

2.0 

k 

PARTE UN CLI IN QUALSIASI MOMENTO / 

(SALVA SCHERMO) 

[TOEBES] 

84 

POPOLI 

III 

★ 

PARTE UN CLI IN QUALSIASI MOMENTO / 

(SALVA SCHERMO) 

[TOEBES] 

65 

RUNBACK 


* 

APRE UN CLI E PARTE IL PROGRAMMA ALLA FINE CHIUDE IL CLI 

[HEATH] 

73 

RUNBACKGROUND 


k 

APRE UN CLI E PARTE IL PROGRAMMA ALLA FINE CHIUDE IL CLI 

[PECK] 

102 

SILICON 



PICCOLA LINEA DI INPUT PER GESTIRE I 

COMANDI AMIGADOS 

[GOODEVE] 

43 

WBRUN 


* 

PERMETTE DI FAR PARTIRE I PROGRAMMI 

WBENCH DA CLI 

[TOEBES] 


COPIATORI DI DISCHI 


98 BACKUP * BACKUP DA HARD DISK A FLOPPY / (MOLTO SEMPLICE) [KENT] 


82 

D2D-DEMO 

2.0 


DEMO DI DISK-2-DISK 

/ (DA CBM DOS2.1 A AMIGA) 

[CENTRAL 

COAST] 

131 

DFC 

1 

* 

FORMATTA/COPIA 


[ROKICKI] 

109 

DOSKWIK 

o 

CN 


COPIATORE VELOCE DI 

RAM A DISCO E VICEVERSA 

[KEMPER] 

129 

DOSKWIK 

2.0 


COPIATORE VELOCE DI 

RAM A DISCO E VICEVERSA 

[KEMPER] 

128 

MRBACKUP 

1.1 

* 

BACKUP DA HARD DISK 

A FLOPPY / (COMPRIME I DATI) 

[RINFRET] 

129 

MRBACKUP 

2.0 

* 

BACKUP DA HARD DISK 

A FLOPPY / (COMPRIME I DATI) 

[RINFRET] 

129 

MRBACKUP 

2.1 


BACKUP DA HARD DISK 

A FLOPPY / (COMPRIME I DATI) 

[RINFRET] 

49 

MYUPDATE 


k 

COPIA FILE CHE ESISTONO GIÀ' NELLA DESTINAZIONE 

[MUELLER] 

35 

QUICKCOPY 

1.0A/EA 


COPIATORI PER DISCHI 

[DEVENPORT] 

128 

SDBACKUP 

1.1 


BACKUP DA HARD DISK 

A FLOPPY / (USA I BIT DI ARCHIVIO) 

[DREW] 

45 

UPDATE 

1.7 


COPIA I FILE PIU' NUOVI DEI FILE DI DESTINAZIONE 



EDITOR DI DISCHI 







50 DISKZAP 

1.1 

EDITOR DI : 

DISCHI 




[BINGHAM JR] 

58 NEWZAP 

3.0 

* EDITOR DI 

DISCHI 




[HODGSON] 

102 SECTORAMA 

1.0 

EDITOR DI 

DISCHI 

/ 

(VISUALIZZA UN 

SETTORE INTERO) 

[JOINER] 

108 SECTORAMA 

1.1 

EDITOR DI 

DISCHI 

/ 

(VISUALIZZA UN 

INTERO SETTORE) 

[JOINER] 


ASSEMBLER 68000/10 






110 A68K 

1.02 

* ASSEMBLER PER 68000 


[GIBBS] 

4 6 ASM 

1.0 

MACRO 

ASSEMBLER 

PER 

68010 

[LEAVITT] 

50 ASM 

1.1 

MACRO 

ASSEMBLER 

PER 

68010 

[LEAVITT] 

66 ASM68K 

1 . 0.1 

MACRO 

ASSEMBLER 

PER 

68000 

[HOWE] 

69 ASM68K 

1.0.3 

MACRO 

ASSEMBLER 

PER 

68000 

[HOWE] 

81 ASM68K 

1 . 1.0 

MACRO 

ASSEMBLER 

PER 

68000 

[HOWE] 


UTILITY ASSEMBLER 68000 

128 DIS * DISASSEMBLER PER 68000 [LEE] 


LINGUAGGIO C 

53 COMPÌLER * COMPILATORE C OTTIMIZZATO / (NON PIENAMENTE PORTABILE) [BRANDT] 

110 PDC 0.2 * COMPILATORE C OTTIMIZZATO [LYDIATT 

(BRANDT)] 


□CO 


"b 


LINGUAGGIO CP/M 














□ 


Transactor per AMIGA 


■ C 


109 SIMCPM 1.00 * EMULATORE CP/M 2.2 / (8080 CPU S TERMINALE H19) [CATHEY/GIBBS] 


LINGUAGGIO DRACO 

76 DRACO DISK 1 
77 DRACO DISK 2 


LINGUAGGIO FORTH 

3 CFORTH * IMPLEMENTAZIONE FACILMENTE PORTABILE DI FIGFORTH [PRATT] 

9 MVP-FORTH 1.03A MOUNTAIN VIEW PRESS FORTH [FANTASIA 

SYSTEMS] 


LINGUAGGIO DRACO / (DISCO DI SISTEMA) [GRAY] 

LINGUAGGIO DRACO / (DISCO DATI) [GRAY] 


LINGUAGGIO LISP 


3 XLISP 
18 XLISP 
39 XLISP 


1.4 * PICCOLO INTERPRETE SPERIMENTALE DI LISP / (NON FUNZIONA) [BETZ] 

1.6 * PICCOLO INTERPRETE SPERIMENTALE DI LISP [BETZ] 

1.7 PICCOLO INTERPRETE SPERIMENTALE DI LISP [BETZ] 


LINGUAGGIO LOGO 

70 LOGO INTERPRETE LOGO / (SIMILE COME USO AL LOGO DELL'APPLEII) [QWENS] 


LINGUAGGIO MODULA2 


113 M2AMIGA 
24 MODULA-2 


1.1 


VERSINE DEMO DI UN COMPILATORE IN UN SOLO PASSAGGIO [AMSOFT] 

VERSIONE INIZIALE DEL COMPILATORE A SINGOLO PASSO ETHZ 


UTILITY PER 68000 

136 SMALLTALK * SERIE DI MACRO PER MIGLIORARE L'INTERFACCIA CON AMIGADOS [LEE] 


PROGRAMMAZIONE 


138 

AMIGALINE 


66 

ASSIGNED 


103 

AVLTREES 

1.0 

34 

BTREE 

1.1 

34 

BTREE2 

1.0 

54 

HANOI 


1 

HELLO 


5 

INPUT.DEV 


5 

JOYSTICK 


5 

KEYBOARD 


79 

KILL 

1.01 

111 

LABELS 


61 

LPATCH 


18 

MC 68010 


5 

MOUSE 


55 

NEWSTARTUPS 


5 

ONE.WINDOW 


87 

PALTEST 


5 

PARALLEL 


73 

PAROUT 


92 

PARSE 


20 

PORTHANDLER 


107 

PROSUITE 

1.01 

20 

RANDOM 


74 

RANDOM 


85 

RAWIO 


5 

TEXT.DEMO 



* 


* 

* 

* 

★ 


★ 


★ 

* 

★ 


* 


■k 

k 


NOTE TECNICHE PER IL PROGRAMMATORE 
PER CONTROLLARE SE UN NOME E STATO ASSEGNATO 
ROUTINE PER CREARE E USARE ALBERI BINARI BILANCIATI 
ROUTINE PER IMPLEMENTARE ALBERI BINARI 

LIBRERIA DI ROUTINE ORIGINALE PER ALBERI BINARI 
TORRE DI HANOI / (DEMO SULLA PROGRAMMAZIONE RICURSIVA) 
'HELLO WORLD' FINESTRA DEMO DA RKM 

GESTISCE LE ECCEZIONI MOUSE/KEYBOARD PRIMA DI INTUITION 
RKM ESEMPIO SULL'UTILIZZO DELLA GAMEPORT CON IL JOYSTICK 
RKM ESEMPIO DI COMUNICAZIONE DIRETTA CON LA TASTIERA 
ELIMINA TASK,CHIUDE FINESTRE, SCARICA CODICI 
AIUTO PER LE COSTANTI DI SISTEMA 

MODIFICA ATOM & PROGRAM. CON MALFUNZIONANTE 1.0 LSTARTUP 
SPIEGAZIONE ISTRUZIONI DEL 68010 E DIFFERENZE CON 68000 

SETTA IL MOUSE NELLA GAMEPORT 2 
NUOVO SET DI MODULI STARTUP PER C 
FINESTRA CON CONSOLE ATTACCATA 

ESEMPIO DI COME TESTARE SE E' UNA MACCHINA PAL 
ESEMPIO DI ACCESSO ALLA PORTA PARALLELA 

ACCESSO ALLA PORTA PARALLELA TRAMITE CIAA./MISC.RESOURCE 

GESTISCE ESPRESSIONI / (COMPUTA & STAMPA I RISULTATI) 

SEMPLICE PORT-HANDLER 

PER PROGRAMMATORI SUITE 1.01 

GENERATORE DI NUMERI CASUALI IN C 

GENERATORE DI NUMERI CASUALI IN C 

ESEMPIO DI INPUT DA RAW & MODALITÀ CBREAK 

RKM ESEMPIO MOSTRANDO VARI CARATTERI S ATTRIBUTI 


[GREEN] 

[VIXIE] 

[HELLIER- 

JEFFERSON] 

[HELLIER] 

[OZER] 

[PECK] 

[PECK] 

[PECK] 

[MUSSER] 

[SEIBERT] 

[SCHEPPNER] 

[FLORYAN- 

TURNER] 

[PECK] 

[SCHEPPNER] 

[PECK] 

[BONNKIRCH] 

[POHORSKY] 

[LINDSAY] 

[OLSEN] 

[TOEBES] 

[MICAL] 

[BEATS] 

[TOOLE] 

[MCMAINS] 

[PECK] 


BEI 















0 


Transactor per AMIGA 


PrScreen("Primo screen nella lista di 

Intuition", IBase->FirstScreen) ; 


break; 


} 

level—; 


void put (option, stuff, base, offset) 

int option; struct StructData *stuff; char *base; 

int offset; 


■ C 


sprintf(buf, "$%8x %10u", inum, inum); 

break; 

case 13: /* stampa un byte */ 

inum = *(base + offset); 

sprintf(buf, "$%8x %10u", inum, inum); 

break; 


strcat(textlines[option], buf); 
ChoiceText[option].IText = (UBYTE *) 
textlines[option]; 


} 


register long Inum; 
register int inum; 
char buf[40]; 
int i ; 

sprintf(textlines[option], "%-l6s%-24s", 

stuff->membername, stuff->membertype) ; 
switch (stuff->printtype) ( 

case 0: /* non stampare niente */ 

buf[0] = '\0'; 
break; 

case 1: /* stampa una long */ 

Inum = *(long *)(base + offset); 
sprintf(buf, "$%81x %01d", Inum, Inum); 

break; 

case 2: /* stampa uno short */ 

inum = *(short *)(base + offset); 
sprintf(buf, "$%8x %10d", inum, inum); 

break; 

case 3: /* stampa un byte */ 

inum = *(base + offset); 

sprintf(buf, "$%8x %10d", inum, inum); 

break; 

case 4: /* stampa una stringa */ 

if (!(Inum = *(long *)(base + offset) )) 
sprintf(buf, "NULL"); 
else ( 

for (i =0; i < 30 SS *((char *)lnum + i); 
i++) 

buffi +1] = *((char *)lnum + i); 
buf[0] = buf [i + 1] - '\"'; 
buf[i + 2] = '\0'; 
if (*((char *)lnum + i) ) 
strcat(buf, "..."); 

} 

break; 

case 5: /* stampa un puntatore */ 

if (!(lnum = *(long *)(base + offset) )) 
sprintf(buf, "NULL"); 
else 

sprintf(buf, "$%81x %101d", Inum, Inum); 

break; 

case 11: /* stampa una long */ 

Inum = *(long *)(base + offset); 

sprintf(buf, "$%81x %101u", Inum, Inum); 

break; 

case 12: /* stampa uno short */ 

inum = *(short *)(base + offset); 


void FlagPrint(string, names, flags) 
char *string, **names; ULONG flags; 

{ 

int i, line, fields = FLAGFIELDS; 
char buf[32]; 

SetBackText(1); /* 'torna indietro' */ 

for (i = 0; i < 8; i++) ( 
strcpy(textlines[i], "-"); 

ChoiceText[i].IText = (UBYTE *)textlines[ì]; 

} 

putHeader(string, NULL); 

for (i = line =0; i < 32; i++) { 

if ((flags & (IL « i)) && names[i]) { 
sprintf (buf, "%-19s", names[i]); 
strcat(textlines[line], buf); 
if (!—fields) { 

ChoiceText[line].IText = (UBYTE *) 
textlines[line]; 

line++; 

fields = FLAGFIELDS; 

} 

} 

) 

if (fields < FLAGFIELDS) 

ChoiceText[line].IText = (UBYTE *) 
textlines[line]; 
while (GetChoice(line + 1)) 


void HexDump(string, address, unit, size) 
char *address, *string; int unit; long size; 

{ 

int line = 0, c; 
char *buf[80]; 

BackIText.IText = (UBYTE *)" interrompi hex 
if (size == -1) 
size = 0x7ffff; 
do ( 

sprintf(buf, "%s da %lx (%ld)", string, 
address, address); 
putHeader(buf, NULL); 
if (line == MAXGADG) 
line - 0; 

while (line < MAXGADG SS size > 0) { 

HexLine(address, unit, line++, size); 


[45] 
















0 


Transactor per AMIGA 


■ n 


size - 16; 

address += 16; 

} 

c = GetChoice(size > 0 ? MAXGADG + 1 : line); 
} while (size > 0 SS c == MOREGADG); 

) 


newstring = malloc(strlen(string) + 1); 
*newstring = 

strcpy(newstring + 1, string); 

ChoiceText[0].IText = (UBYTE *)newstring; 
GetChoice(1); 
free(newstring); 


void HexLine (address, unit, line, size) 

UBYTE *address; int unit, line; long size; 

{ 

USHORT i, j; 
char buf[80]; 

static char hexdigit [] = "0123456789ABCDEF"; 
sprintf(textlines[line], "-%61x: ", address); 
for (i =0; i < MIN(size, 16); i += unit) { 
switch (unit) { 
case BYTESIZE: 

j = *(address + i); 

sprintf(buf, "%c%c ", hexdigit[j / 16], 
hexdigit[j % 16]); 

break; 

case INTSIZE: 

sprintf(buf, "%04x ", *(short *)(address + 
i) ) ; 

break; 

case PTRSIZE: 

sprintf(buf, "%081x ", *(long *)(address + 

i) ) ; 

break; 

} 

strcat(textlines[line], buf); 

} 

ChoiceText[line].IText = (UBYTE *)textlines[line]; 


int SetOptionText (hdrtext, data, object, size, 
offset) 

char *hdrtext; 

struct StructData *data; 

APTR object; 
int size, offset; 

( 

int i, sum; 

SetBackText( offset ? 1 : 0); 

putHeader(hdrtext, object); 

for (i = sum =0; i < size; i++) ( 

put(i, &data[i], object, sum + offset); 
sum += data[i].datasize; 

} 

return (sum + offset); 


void PrString(heading, string) char *heading, 
*string; 

{ 

char *newstring, *malloc(); 
putHeader(heading, NULL); 


Listato 3: 


#include "sb.h" 


#define 
#define 
#define 
#define 
#define 
(long)y); 


CHOICEWIDTH 280 
CHOICEHEIGHT 8 
SPACING 9 
TOPGADG 30 
PUTTEXT(text, x, 


y) ( Movefrp, (long)x, 
Text(rp, text. 


(long)strlen(text)); } 

struct IntuitionBase *IntuitionBase = NULL; 
struct GfxBase *GfxBase = NULL; 

struct Window *OpenWindow(), *MainWindow = 

NULL; 

struct RastPort *rp; 

extern int level; 

APTR OpenLibrary(); 

struct IntuiText ChoiceText[MAXGADG + 1]; 

struct Gadget ChoiceGadg[MAXGADG + 1]; 

extern void CloseOutO, Redisplay (); 


struct IntuiText BackIText = { 
3, 2, JAM2, 

5, 2, 

NULL, NULL, NULL 


struct IntuiText MorelText = { 

2, 3, JAM2, 

5 , 2 , 

NULL, 

(UBYTE *)"ancora", 

NULL 

} ; 

struct Gadget BackGadg = { 

NULL, 

10, -12, 140, 12, 

GADGHCOMP | GRELBOTTOM, 
RELVERIFY, 

BOOLGADGET, 

NULL, NULL, SBackIText, 

NULL, NULL, 

0, NULL /* gadget ID è zero */ 

} ; 

struct Gadget MoreGadg = { 

NULL, 

300, -12, 59, 12, 

GADGHCOMP | GRELBOTTOM, 


nu 


t] 
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RELVERIFY, 

BOOLGADGET, 

NULL, NULL, SMorelText, 

NULL, NULL, 

MOREGADG, NULL 

} ; 

struct NewWìndow NWindow = { 

0, 10, 640, 189, /* left, top, 

width, height */ 

-1, -1, /* usa i colori 

dello screen */ 

GADGETUP /* IDCMP flags */ 

| CLOSEWINDOW, 

WINDOWDEPTH /* window flags */ 

I WINDOWCLOSE 
I WINDOWDRAG 
| RMBTRAP 
I ACTIVATE 
| NOCAREREFRESH 
| SMART_REFRESH, 

SBackGadg, /* primo gadget nella lista */ 
NULL, 

(UBYTE *)"The Transactor Structure Browser 
V 1.0", 

NULL, NULL, 

0 , 0 , 0 , 0 , 

WBENCHSCREEN 


APTR IAddr; /* puntatore al gadget fornito da 

IDCMP */ 

Redisplay(num); /* prepara le scelte nella 

finestra */ 

FOREVER { /*** loop principale ***/ 

Wait (IL << MainWindow->UserPort->mp_SigBit); 
while (message = GetMsg(MainWindow->UserPort)) { 

/* prendi dalla message port 
quello che ci serve */ 
msgclass = message->Class; 

IAddr = message->IAddress; 

ReplyMsg(message); /* rispondi subito al 

messaggio */ 

/* verifica se è stato selezionato un 
gadget */ 

if (msgclass == GADGETUP) 

return ( (int)((struct Gadget *) 

IAddr)->GadgetID ); 

/* chiudi tutto se è stato selezionato 
CLOSEWINDOW */ 

else if (msgclass == CLOSEWINDOW) 

CloseOutO; /* pulisci ed esci */ 

' ) 

} 

return(0); /* dummy */ 


void SetupGadg() 

{ 

int i; 

for (i =0; i < 


MAXGADG; i++) ( 


void putHeader(string, ptr) char *string; APTR ptr; 
/* metti titolo e puntatore in cima allo screen - 
* se ptr == NULL, metti solo la stringa. */ 

{ 

char buf[80]; 

SetAPen(rp, 0L); 


ChoiceText[i].BackPen 

= 

0; 

RectFillfrp, IL 

, 10L, (long)MainWindow->Wìdth-25 

ChoiceText[i].DrawMode 

= 

JAM2 ; 


27L) ; 

ChoiceText[i].LeftEdge 

= 

0; 

SetAPenfrp, 3L) 


ChoiceText[i].TopEdge 

= 

0; 

if (ptr) { 


ChoiceText[i].ITextFont 

= 

NULL; 

sprintf(buf, 

"%d: %s (address $%lx):", level, 

ChoiceText[i].IText 

= 

NULL; 


string, ptr); 

ChoiceText[i].NextText 

= 

NULL; 

PUTTEXT( 


ChoiceGadg[i].LeftEdge 

= 

20; 

" Membro 

Tipo 

ChoiceGadg[i].TopEdge 

= 

i * SPACING + 


Valore(hex/decimal)", 

TOPGADG; 


20L, 10L + 2 

* rp->TxHeight); 

ChoiceGadg[i].Width 

= 

CHOICEWIDTH; 

} 


ChoiceGadg[i].Height 

= 

CHOICEHEIGHT; 

else 


ChoiceGadg[i].Flags 

= 

GADGHCOMP; 

sprintf(buf. 

"%d: %s:", level, string); 

ChoiceGadg[i].Activation 

= 

RELVERIFY; 

PUTTEXT(buf, 20L, 10L + rp->TxHeight); 

ChoiceGadg[i].GadgetType 

= 

BOOLGADGET; 

) 


ChoiceGadg[i].GadgetText 

= 

SChoiceText[i]; 



ChoiceGadg[i].GadgetlD 

= 

i + 1; /* gadget 




ID incomincia da 1 */ 


int GetChoice (num) int num; 

{ 

struct IntuiMessage *GetMsg(), ‘message; 

ULONG msgclass; /* classe del messaggio di IDCMP */ 


void OpenStuff () 

{ 

if (!(IntuitionBase = (struct IntuitionBase *) 

OpenLibrary("intuition.library", 0L) ) ) 
CloseOut(); 

if (!(GfxBase = (struct GfxBase *) 

OpenLibrary("graphics.library", 0L) ) ) 
CloseOut ( ); 

if (!(MainWindow = OpenWindow(SNWindow)) ) 


nn 
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CloseOut(); 

rp = MainWindow->RPort; /* rastport per le 
routine grafiche */ 


void CloseOut() 

{ 

/* chiudi tutto prima di uscire */ 
if (MainWindow) CloseWindow(MainWindow); 
if (IntuitionBase) CloseLibrary(IntuitionBase) , 
if (GfxBase) CloseLibrary(GfxBase); 

exit (0) ; 


void Redisplay(num) int num; 

/* pulisci la window, rimuovi i vecchi gadget, 
prepara e aggiungi quelli nuovi */ 


void SetBackText (sflag) int sflag; 

{ 

BackIText.IText = (UBYTE *)(sflag ? 

" pagina preced " : " torna indietro "); 


Listato 4: 


♦include "sb.h" 
extern int level; 


void PrGadget(string, gadget) char *string; struct 
Gadget *gadget; 

( 

static struct StructData structdata[] = { 


{ 

{ 

" NextGadget", 

"struct Gadget 

5, 

PTRSIZE 

} 

struct Gadget *gadg; 

( 

"-LeftEdge", 

"SHORT ", 

2, 

INTSIZE 

) 

BOOL MoreFlag = FALSE; 

{ 

"-TopEdge", 

"SHORT", 

2, 

INTSIZE 

) 

int i, c; 

{ 

"-Width", 

"SHORT", 

2, 

INTSIZE 

} 

SetAPenfrp, 0L) ; /* rectfill con colore di 

{ 

"-Height", 

"SHORT", 

2, 

INTSIZE 

) 

background per pulire */ 

{ 

" Flags", 

"USHORT", 

12, 

INTSIZE 

} 

RectFill(rp, IL, (long)TOPGADG, 

{ 

" Activation", 

"USHORT", 

12, 

INTSIZE 

} 

(long)MainWindow->Width - 2, 

( 

" GadgetType", 

"USHORT", 

12, 

INTSIZE 

} 

(long)MainWindow->Height - 2); 

( 

"(GadgetRender" 

"APTR)", 

5, 

PTRSIZE 

> 

if (num > MAXGADG) { 

{ 

" (SelectRender" 

"APTR) ", 

5, 

PTRSIZE 

} 

num = MAXGADG; 

< 

" GadgetText", 

'struct IntuiText *" 

, 5, 

PTRSIZE 

} 

MoreFlag = TRUE; /* prepara il gadget "ancora" */ 

{ 

"-MutualExclude 

,"LONG", 

1, 

PTRSIZE 

} 

) 

{ 

" (Speciallnfo", 

"APTR)", 

5, 

PTRSIZE 

> 

/* rimuovi tutti i gadget delle opzioni */ 

{ 

"-GadgetlD", 

"USHORT", 

12, 

INTSIZE 

} 

gadg = SBackGadg; 

{ 

"-UserData", 

"APTR", 

5, 

PTRSIZE 

} 


while (gadg = gadg->NextGadget) 

RemoveGadget(MainWindow, gadg); 

/* visuakizza i gadget a seconda del codice che 
* si trova all'inizio dell'IText di ogni gadget */ 
for (i = 0; i < num; i++) ( 

ChoiceText[i].FrontPen = 1; 

if ((c = *ChoiceText[i].IText) == '-' Il c == '(') 

{ 

if (c == '-') ( 

*ChoiceText[i].IText = ' '; 

ChoiceText[i].FrontPen = 2; 

} 

PrintIText(rp, SChoiceText[i], 

(long)ChoiceGadg[i].LeftEdge, 

(long)ChoiceGadg[i].TopEdge); 

} 

else 

AddGadget(MainWindow, SChoiceGadg[i], -IL); 

} 

if (MoreFlag) 

AddGadget(MainWindow, SMoreGadg, -IL); 

/* visualizza i gadget (il testo) */ 

RefreshGadgets(SBackGadg, MainWindow, NULL); 


} ; 

static char *flagnames[16] = { 

"GADGHBOX", "GADGHIMAGE", 

"GADGIMAGE", "GRELBOTTOM", 

"GRELRIGHT", "GRELWIDTH”, 

"GRELHEIGHT", "SELECTED", 

"GADGDISABLED" 

} ; 

static char ‘activatenames[16] = { 

"RELVERIFY", "GADGIMMEDIATE", 

"ENDGADGET", "FOLLOWMOUSE", 

"RIGHTBORDER", "LEFTBORDER", 

"TOPBORDER", "BOTTOMBORDER", 

"TOGGLESELECT", "STRINGCENTER", 

"STRINGRIGHT", "LONGINT", 

"ALTKEYMAP", "BOOLEXTEND" 

} ; 

static char *systypenames[16] = ( 

"SIZING", "WDRAGGING", 

"SDRAGGING", "WUPFRONT", 

"SUPFRONT", "WDOWNBACK", 

"SDOWNBACK", "CLOSE", 

NULL, NULL, 

NULL, NULL, 

"REQGADGET", "GZZGADGET", 

"SCRGADGET", "SYSGADET" 
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} ; 

static char *applitypenames[16] = { 
"BOOLGADGET”, "GADGET0002", 

"PROPGADGET", "STRGADGET", 


NULL, 

NULL, 

NULL, 


NULL, 

NULL, 

NULL, 


NULL, NULL, 

"REQGADGET", "GZZGADGET", 

"SCRGADGET", "SYSGADGET" 


OxOf) - 1)); 

FXagPrint("Flag che definiscono il tipo 
di questo gadget", 
applitypenames, (ULONG)bits); 

} 

break; 
case 11: 

if (gadget->GadgetText) 

PrlntuiText("Prima struttura XntuiText 
nella lista", 


} ; 

int sum, choice = -1; 

USHORT bits; 
level++; 

while (choice) { 

sum = SetOptionText(string, structdata, 

(APTR)gadget, DATASIZE, 0); 
switch (choice = GetChoice(DATASIZE)) { 

case 1 : 

if (gadget->NextGadget) 

PrGadget("Gadget successivo nella lista 
di Intuition", gadget->NextGadget); 

break; 
case 6: 

bits = gadget->Flags; 
switch (bits & GADGHIGHBITS) { 
case 0: 

flagnames[0] = "GADGHCOMP"; 
bits |= 0x01; 
break; 
case 1 : 

flagnames[0] = "GADGHBOX"; 
break; 
case 2: 

flagnames[1] = "GADGHIMAGE"; 
break; 
case 3: 

flagnames[1] = "GADGHNONE"; 

bits A = 0x01; 

break; 

) 

FlagPrint("Flag di questo gadget", 
flagnames, (ULONG)bits); 

break; 
case 7 : 

FlagPrint("Flag di attivazione di questo 
gadget", 

activatenames, (ULONG)gadget->Activation); 
break; 
case 8 : 

bits = gadget->GadgetType; 
if (bits & SYSGADGET) { 

bits = (bits & OxffOO) | (1 « (((bits & 

OxfO) » 4) - 1)) ; 

FlagPrint("Flag che definiscono il tipo 
di questo gadget", 
systypenames, (ULONG)bits); 

} 

else { 

bits = (bits & OxffOO) | (1 << ( (bits & 


gadget->GadgetText); 

break; 

} 

} 

level— ; 


Listato 5: 

♦include "sb.h" 
extern int level; 

extern void PrPlanesO, PrRastPort2 ( ) ; 


void PrBitMap(string, bitmap) char *string; struct 
BitMap *bitmap; 

( 

static struct StructData structdata[] = ( 


{ 

"-BytesPerRow", 

"UWORD”, 

CnJ 
i—H 

INTSIZE 

) 

{ 

"-Rows", 

"UWORD", 

12, 

INTSIZE 

} 

( 

"-Flags", 

"UBYTE", 

13, 

BYTESIZE 

} 

{ 

"-Depth", 

"UBYTE", 

13, 

BYTESIZE 

} 

{ 

"-Pad", 

"UWORD", 

12, 

INTSIZE 

i 

{ 

" Planes[8]", 

"PLANEPTR" 

, 5, 

PTRSIZE * 

8} 


} ; 

int sum, choice = -1; 
level++; 

while (choice) { 

sum = SetOptionText(string, structdata, 

(APTR)bitmap, DATASIZE, 0); 
if ((choice = GetChoice(DATASIZE)) == 6) 

PrPlanes("BitPlane appartenenti a questa 
BitMap", bitmap->Planes, 
bitmap->Rows, bitmap->BytesPerRow); 

} 

level—; 


void PrPlanes(string, planes, rows, bytes) 
char *string; PLANEPTR planes[]; UWORD rows, bytes; 
( 

static struct StructData structdata[] = { 


{" 

BitPlane[0]", 

"PLANEPTR", 

5, 

PTRSIZE 

i 

f" 

BitPlane[1]", 

"PLANEPTR", 

5, 

PTRSIZE 

) 


BitPlane[2]", 

"PLANEPTR", 

5, 

PTRSIZE 

) 
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' BitPlane[3]", 

"PLANEPTR", 

5, 

PTRSIZE 

1 BitPlane[4]", 

"PLANEPTR", 

5, 

PTRSIZE 

' BitPlane[5]", 

"PLANEPTR", 

5, 

PTRSIZE 

' BitPlane[6]", 

"PLANEPTR", 

5, 

PTRSIZE 

' BitPlane[7]" , 

"PLANEPTR", 

5, 

PTRSIZE 


ìnt sum, choice = -1; 
level++; 


level—; 


vcid PrRastPort2(string, rastport, offset) 
char *string; struct RastPort *rastport; int offset; 
{ 

static struct StructData structdata[] = { 


while (choice) ( 


)"-cp_x", 

"SHORT", 

2, 

INTSIZE }, 

sum = SetOptionText(string, structdata, 

{"-cp_y", 

"SHORT", 

2, 

INTSIZE ), 

(APTR)planes, 

DATASIZE, 0); 

(" minterms[8]", 

"UBYTE", 

0, 

BYTESIZE * 8}, 

choice = GetChoice(8); 


{"-PenWidth", 

"SHORT", 

2, 

INTSIZE }, 

if (choice >= 1 && choice <= 8 SS 

planes[choice 

("-PenHeight", 

"SHORT", 

2, 

INTSIZE }, 

- 1]) 


{"(TextFont", 

"struct Font *) 

",5, 

PTRSIZE }, 

HexDump(structdata[choice - 1]. 

membername. 

("-AlgoStyle", 

"UBYTE", 

13, 

BYTESIZE }, 

planes[choice - 1], PTRSIZE, 

(long) (rows * 

{"(TxFlags", 

"UBYTE", 

13, 

BYTESIZE }, 

bytes)); 


{"-TxHeight", 

"UWORD", 

12, 

INTSIZE }, 

} 


{"-TxWidth", 

"UWORD", 

12, 

INTSIZE }, 

level—; 


{"-TxBaseLine", 

"UWORD", 

12, 

INTSIZE }, 

} 


{"-TxSpacing", 

"WORD", 

2, 

INTSIZE }, 



{"-RP User", 

"WORD", 

2, 

INTSIZE }, 



{" wordreserved[7] 

", "UWORD", 

0, 

INTSIZE * 7 }, 

void PrRastPort(string, rastport) char *string; 

{" longreserved[2] 

", "ULONG", 

0 , 

PTRSIZE * 2 }, 

struct RastPort *rastport; 


{" reserved[8]", 

"UBYTE", 

0 , 

BYTESIZE * 8} 


static struct StructData structdata[] = { 


} ; 

int sum, choice 


- 1 ; 


{ 

"(Layer", 

"struct Layer *)", 

5, 

PTRSIZE 

}, 

level++; 

{ 

" BitMap", 

"struct BitMap *", 

5, 

PTRSIZE 

}, 

while (choice) { 

( 

"-Area Ptrn", 

"USHORT *", 

5, 

PTRSIZE 

}, 

sum = SetOptionText(string, structdata, 

{ 

"(TmpRas", 

"struct TmpRas *)", 

5, 

PTRSIZE 

}, 

(APTR)rastport, DATASIZE, offset) 

( 

"(Arealnfo", 

"struct Arealnfo *) 

', 5, 

PTRSIZE 

}, 

switch (choice = GetChoice(DATASIZE)) { 

{ 

"(Gelslnfo", 

"struct Gelslnfo *) 

5, 

PTRSIZE 

t. 

case 3: 

{ 

"-Mask", 

"UBYTE", 

13, 

BYTESIZE 

}, 

HexDump("Stampa esadecimale dei byte di 

{ 

"-FgPen", 

"BYTE", 

3, 

BYTESIZE 

}, 

minterm", 

{ 

"-BgPen", 

"BYTE", 

3, 

BYTESIZE 

}, 

&rastport->minterms[0], BYTESIZE, 

{ 

"-AOlPen", 

"BYTE", 

3, 

BYTESIZE 

}, 

(long)BYTESIZE * 8); 

{ 

"-DrawMode", 

"BYTE", 

3, 

BYTESIZE 

}, 

break; 

{ 

"-AreaPtSize" 

"BYTE", 

3, 

BYTESIZE 

), 

case 14: 

{ 

"-linpatcnt", 

"BYTE", 

3, 

BYTESIZE 

>, 

HexDump("Stampa esadecimale di word 

{ 

"-dummy", 

"BYTE", 

3, 

BYTESIZE 

}, 

riservate", 

f 

"(Flags", 

"USHORT", 

12, 

INTSIZE 

>, 

S rastport->wordreserved[0], 

{ 

"-LinePtrn", 

"USHORT", 

• 

i—1 

INTSIZE 

} 

INTSIZE, (long)INTSIZE * 7); 

} ; 






break; 

int 

sum, choice = 

-1; 




case 15: 


level++; 

while (choice) { 

sum = SetOptionText(string, structdata, 

(APTR)rastport, DATASIZE, 0) ; 
switch (choice = GetChoice(MAXGADG +1)) { 

case 2: 

if (rastport->BitMap) 

PrBitMap("BitMap di questa RastPort", 
rastport->BitMap) ; 

break; 

case MOREGADG: 

PrRastPort2("Membri della struttura 

RastPort (pagina 2)", rastport, sum), 

break; 

} 


HexDump("Stampa esadecimale di longword 
riservate", 

&rastport->longreserved[0], 
PTRSIZE, (long)PTRSIZE * 2); 
break; 
case 16: 

HexDump("Stampa esadecimale di byte 
riservati", 

&rastport->reserved[0], BYTESIZE, 


(long)BYTESIZE 
break; 


level—; 


)) , 
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Listato 6: 

/* module written by G. Gagnon, Mar 24, 1987 */ 
♦include "sb.h" 
extern int level; 

void PrlntuiText(string, intuitext) char ‘string; 
struct IntuiText ‘intuitext; 

{ 

static struct StructData structdata[] = ( 


-FrontPen", 

"UBYTE", 

3, 

BYTESIZE 

), 

-BackPen", 

"UBYTE”, 

3, 

BYTESIZE 

), 

-DrawMode", 

"UBYTE”, 

3, 

INTSIZE 

), 

-LeftEdge ", 

"SHORT”, 

2, 

INTSIZE 

), 

-TopEdge”, 

"SHORT”, 

2, 

INTSIZE 

), 

ITextFont ,f 

,"struct TextAttr 

5, 

PTRSIZE 

}, 

IText”, 

"UBYTE *", 

4, 

PTRSIZE 

}, 

NextText", 

"struct IntuiText *", 

, 5, 

PTRSIZE 

) 


} ; 

int suiti, choice = -1; 
level++; 

while (choice) { 

sum = SetOptionText(string, structdata, 

(APTR)intuitext, DATASIZE, 0); 
switch (choice = GetChoice(DATASIZE)) ( 

case 6: 

if (intuitext->ITextFont) 

PrTextAttr("Struttura 

TextAttr",intuitext->ITextFont) ; 
break; 
case 7 : 

PrString("Testo puntato da IText", 
intuitext->IText); 

break; 
case 8 : 

if (intuitext->NextText) 

PrlntuiText("Struttura IntuiText 
successiva nella lista", 

intuitext->NextText); 

break; 

) 

} 

level—; 


Listato 7: 

/* module written by G. Gagnon, Mar 24, 1987 */ 
♦include "sb.h" 


void PrMsgPort(string, msgport) char ‘string; 
struct MsgPort ‘msgport; 

( 

static struct StructData structdata[] = { 


-mp Node", 

"Node structure", 

0, 

0 ), 

.In Succ", 

"struct Node 

5, 

PTRSIZE }, 

.In Pred", 

"struct Node *", 

5, 

PTRSIZE }, 

- .In Type", 

"UBYTE", 

13, 

BYTESIZE), 

.In Pri", 

"BYTE", 

3, 

BYTESIZE), 

.In Name", 

"CHAR *", 

4, 

PTRSIZE ), 

-mp Flags", 

"UBYTE", 

13, 

BYTESIZE), 

-mp SigBit" 

"UBYTE", 

13, 

BYTESIZE), 

(mp SigTask", 

"struct Task *)", 

5, 

PTRSIZE ), 

-mp MsgList", 

"List structure", 

0, 

0 ), 

■Ih Head", 

"struct Node *", 

5, 

PTRSIZE ), 

.lh_Tail", 

"struct Node *", 

5, 

PTRSIZE }, 

.Ih TailPred" 

, "struct Node 

. 5, 

PTRSIZE ), 

.Ih Type", 

"UBYTE", 

13, 

BYTESIZE) , 

.1 pad", 

"UBYTE", 

13, 

BYTESIZE) 


) ; 

int sum, choice = -1; 
level++; 

while (choice) { 

sum = SetOptionText(string, structdata, 

(APTR)msgport, DATASIZE, 0); 
switch (choice = GetChoice(DATASIZE)) { 

case 2 : 

if (rasgport->mp_Node.ln_Succ) 

PrNode("MsgPort->mp_Node.ln_Succ", 
msgport->mp_Node.ln_Succ); 

break; 
case 3: 

if (msgport->mp_Node.ln_Pred) 

PrNode("MsgPort->mp_Node.ln_Pred", 
msgport->mp_Node.ln_Pred); 

break; 
case 6: 

PrString("rap_Node->ln_Name", 

msgport->mp_Node.ln_Name); 

break; 
case 11: 

if (msgport->mp_MsgList.lh_Head) 

PrNode("MsgPort->mp_MsgList.lh_Head", 
msgport->mp_MsgList.lh_Head); 

break; 
case 12: 

if (msgport->mp_MsgList.lh_Tail) 

PrNode("MsgPort->mp_MsgList.lh_Tail", 
msgport->mp_MsgList.lh_Tail); 

break; 
case 13: 

if (msgport->mp_MsgList.lh_TailPred) 

PrNode("MsgPort->mp_MsgList.lh_TailPred" , 
msgport->mp_MsgList.lh_TailPred); 

break; 

} 


extern int level; 


level—; 
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Listato 8: 


/* module written by G. Gagnon, Mar 24, 1987 */ 
♦include "sb.h" 
extern int level; 


void PrNode(string, node) char 
struct Node *node; 

{ 


“'st ring; 


-Height", 

"SHORT", 

2, 

INTSIZE 


-MouseY", 

"SHORT", 

2, 

INTSIZE 1 

>, 

-MouseX", 

"SHORT", 

2, 

INTSIZE 

}, 

Flags", 

"USHORT", 

12, 

INTSIZE 

}, 

Title", 

"UBYTE *", 

4, 

PTRSIZE 

), 

DefaultTitle" 

,"UBYTE *", 

4, 

PTRSIZE 

}, 

-BarHeight", 

"BYTE", 

3, 

BYTESIZE 

}, 

-BarVBorder", 

"BYTE", 

3, 

BYTESIZE 

}, 

-BarHBorder", 

"BYTE", 

3, 

BYTESIZE 

}, 

-MenuVBorder", 

"BYTE", 

3, 

BYTESIZE 

i, 

-MenuHBorder", 

"BYTE", 

3, 

BYTESIZE 

} 


static char *flagnames[8] = { 


static struct StructData structdata[] 

= 

{ 


"WBENCHSCREEN", 

"CUSTOMSCREEN 

( " In Succ", 

"struct Node *", 

5, 

, PTRSIZE 


NULL, 

NULL, 

( " In Pred", 

"struct Node 

5, 

, PTRSIZE 

>, 

"SHOWTITLE", 

"BEEPING", 

{ "-ln_Type", 

"UBYTE", 

4, 

, BYTESIZE 

>, 

"CUSTOMBITMAP", NULL 

{ "-ln_Pri", 

"BYTE", 

3, 

, BYTESIZE 

}. 

} ; 


{ " In Name", 

"UBYTE *", 

4, 

, PTRSIZE 

} 

int sum, choice = -1; 


} ; 





ULONG bits; 


int sum, choice = 

-1; 




level++; 



level++; 

while (choice) { 

sum = SetOptionText(string, structdata, 
(APTR)node, DATASIZE, 0) ; 
switch (choice = GetChoice(DATASIZE)) { 

case 1 : 

if (node->ln_Succ) 

PrNode("Node->ln_Succ", node->ln_Succ); 
break; 
case 2 : 

if (node->ln_Pred) 

PrNode("Node->ln_Pred", node->ln_Pred); 
break; 
case 5: 

PrString("ln_Name",node->ln_Name); 
break; 

} 

} 

level--; 


0 ) ; 


^string; 


Listato 9: 


♦include "sb.h" 
extern int level; 
extern void PrScreen2(); 

void PrScreen(string, screen) char 
struct Screen *screen; 

{ 

static struct StructData structdata[] = { 

{ 

{ 

( 

{ 

{ 


while (choice) { 

sum = SetOptionText(string, structdata, 

(APTR)screen, DATASIZE, 
switch (choice = GetChoice(MAXGADG +1)) { 

case 1: 

if (screen->NextScreen) 

PrScreen("Screen successivo nella lista di 
Intuition", screen->NextScreen); 

break; 
case 2: 

if (screen->FirstWindow) 

PrWindow("Prima window dello screen", 
screen->FirstWindow); 

break; 
case 9: 

if ((bits = screen->Flags) s 2) 
bits "= 1; 

FlagPrint("Flag dello screen", flagnames, 
bits) ; 

break; 
case 10: 

PrString("Titolo attuale dello screen", 
screen->Title); 

break; 
case 11: 

PrString("Titolo di default dello screen", 
screen->DefaultTitle); 

break; 

case MOREGADG: 

PrScreen2("Membri della struttura Screen 
(pagina 2)", screen, sum); 

break; 


' NextScreen", 

"struct Screen *" 

5, 

PTRSIZE 

}, 

level--; 

' FirstWindow", 

"struct Window *" 

5, 

PTRSIZE 

), 

} 

'-LeftEdge", 

"SHORT", 

2, 

INTSIZE 

>, 


'-TopEdge", 

"SHORT", 

2, 

INTSIZE 



'-Width", 

"SHORT", 

2, 

INTSIZE 

>, 

void PrScreen2 
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char *string; struct Screen ‘screen; int offset; 


static struct StructData structdata[] 


extern int level; 


{ 

"-WBorTop", 

"BYTE", 


3, 

BYTESIZE }, 

void PrTextAttr(string, textattr) char 

*string; 

{ 

"-WBorLeft", 

"BYTE", 


3, 

BYTESIZE }, 

struct 

TextAttr *textattr; 



( 

"-WBorLeft", 

"BYTE", 


3, 

BYTESIZE }, 

{ 




{ 

"-WBorBottom" 

"BYTE", 


3, 

INTSIZE }, 

static struct StructData structdata[] = 

< 


{ 

" Font", 

"struct 

TextAttr *' 

, 5, 

PTRSIZE }, 

{ " ta Name", 

"UBYTE *", 

4, 

PTRSIZE } 

{ 

"(ViewPort", 

"struct 

ViewPort)", 

0,SZ(ViewPort)}, 

{ "-ta YSize" 

, "UWORD", 

2, 

INTSIZE } 

{ 

" RastPort", 

"struct 

RastPort ", 

0,SZ(RastPort)}, 

{ "-ta Style" 

, "UBYTE", 

3, 

BYTESIZE } 

{ 

" BitMap", 

"struct 

BitMap", 

0, SZ(BitMap) }, 

{ "-ta_Flags" 

, "UBYTE", 

3, 

BYTESIZE } 

{ 

"(Layerlnfo", 

"struct 

Layer Info) 

", o 


}; 





FirstGadget", "struct Gadget 


-DetailPen", 
-BlockPen", 
-SaveColorO" 
(BarLayer", 
(ExtData", 
(OserData", 


"UBYTE", 

"GBYTE", 
"USHORT", 
"struct Layer 
"GBYTE *)", 
"GBYTE *)", 


SZ(Layer_Info) }, 

5, PTRSIZF, 
13, BYTESIZE 
13, BYTESIZE 
12, INTSIZE 
5, PTRSIZE 
5, PTRSIZE 
5, PTRSIZE 


int sum, choice = -1; 
level++; 

while (choice) { 

sum = SetOptionText(string, structdata, 

(APTR)screen, DATASIZE, offset); 
switch (choice — GetChoice(DATASIZE)) { 

case 5: 

if (screen->Font) 

PrTextAttr("Struttura 

TextAttr",screen->Font); 

break; 
case 7 : 

PrRastPort("RastPort dello screen", 
&screen->RastPort); 

break; 
case 8: 

PrBitMap("BitMap dello screen", 
&screen->BitMap); 

break; 
case 10: 

if (screen->FirstGadget) 

PrGadget("Primo gadget dello screen", 
screen->FirstGadget); 

break; 

) 

} 

level—; 


Listato 10: 

/* module written by G. Gagnon, Mar 24, 1987 */ 
♦include "sb.h" 


int sum, choice = -1; 
level++; 

while (choice) { 

sum = SetOptionText(string, structdata, 
(APTR)textattr, DATASIZE, 0); 
switch (choice = GetChoice(DATASIZE)) { 
case 1: 

PrString("taName", textattr->ta_Name); 
break; 


level—; 


Listato 11: 


♦include "sb.h" 
extern int level; 

extern void PrWindow2(), PrWindow3(), 


void PrWindow(string, window) char *string; 
struct Window ‘window; 

{ 

static struct StructData structdata[] = { 

{ 

( 

{ 

{ 

{ 

( 


) ; 

static char *flagnames[32] = { 


" NextWindow", 

"struct Window 

5, 

PTRSIZE ), 

"-LeftEdge", 

"SHORT", 

2, 

INTSIZE }, 

"-TopEdge", 

"SHORT", 

2, 

INTSIZE ), 

"-Width", 

"SHORT", 

2, 

INTSIZE }, 

"-Height”, 

"SHORT", 

2, 

INTSIZE }, 

"-MouseY", 

"SHORT", 

2, 

INTSIZE }, 

"-MouseX", 

"SHORT", 

2, 

INTSIZE }, 

"-MinWidth", 

"SHORT", 

2, 

INTSIZE ), 

"-MinHeight", 

"SHORT", 

2, 

INTSIZE }, 

"-MaxWidth", 

"SHORT", 

2, 

INTSIZE ), 

"-MaxHeight", 

"SHORT", 

2, 

INTSIZE ), 

" Flags", 

"ULONG", 

11, 

PTRSIZE }, 

"(MenuStrip", 

"struct Menu *)", 

5, 

PTRSIZE ), 

" Title", 

"UBYTE 

4, 

PTRSIZE }, 

"(FirstRequest" 

, "struct Requester 

*) " 

5, 


PTRSIZE 

), 

"(DMRequest", 

"struct Requester *] 

", 5 

PTRSIZE} 
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"WINDOWSIZING", "WINDOWDRAG", 

"WINDOWDEPTH", "WINDOWCLOSE", 

"SIZEBRIGHT", "SIZEBOTTOM", 

"SIMPLE_REFRESH", "OTHER_REFRESH" 
"BACKDROP", "REPORTMOUSE", 

"GIMMEZEROZERO", "BORDERLESS", 
"ACTIVATE", "WINDOWACTIVE", 

"INREQUEST", "MENUSTATE", 


"RMBTRAP", 

NULL, 

NULL, 

NULL, 

"WINDOWREFRESH", 


"NOCAREREFRESH", 

NULL, 

NULL, 

NULL, 

"WBENCHWINDOW", 


"WINDOWTICKED " 


- 1 ; 


int sum, choice = 

ULONG bits; 
level++; 

while (choice) { 

sum = SetOptionText(string, structdata, 

(APTR)window, DATASIZE, 0); 
switch (choice = GetChoice(MAXGADG +1)) { 
case 1 : 

if (window->NextWindow) 

PrWindow("Window successiva nella lista 
di Intuition", window->NextWindow); 

break; 
case 12: 

bits = window->Flags & ~SUPER_UNUSED; 
switch ((bits & REFRESHBITS) » 6) { 

case 0: 

flagnames[6] = "SMART_REFRESH"; 
bits |= 0x40; 
break; 
case 1 : 

flagnames[6] = "SIMPLE_REFRESH"; 
break; 
case 2 : 

flagnames[7] = "SUPER_BITMAP"; 
break; 
case 3: 

flagnames[7] = "OTHER_REFRESH"; 

bits A = 0x40; 

break; 

} 

FlagPrint("Flag della window", flagnames, 
bits); 

break; 
case 14: 

PrString("Titolo della window", 
window->Title); 

break; 

case MOREGADG: 

PrWindow2("Membri della struttura Window 
(pagina 2)", window, sum); 

break; 

} 

} 

level—; 


void PrWindow2(string, window, offset) 
char *string; struct Window *window; int offset; 
{ 

static struct StructData structdata[] = { 


’-ReqCount", 

"SHORT" , 

2, 

INTSIZE 

), 

1 WScreen", 

"struct Screen 

5, 

PTRSIZE 

}, 

' RPort", 

"struct RastPort 

5, 

PTRSIZE 

}, 

’-BorderLeft", 

"BYTE" , 

3, 

BYTESIZE 

}, 

’-BorderTop", 

"BYTE" , 

3, 

BYTESIZE 

), 

’ -BorderRight", 

"BYTE", 

3, 

BYTESIZE 

}, 

’-BorderBottom’ 

,"BYTE", 

3, 

BYTESIZE 

}, 

’ BorderRPort", 

"struct RastPort *" 

, 5, 

PTRSIZE 

}, 

1 FirstGadget", 

"struct Gadget *", 

5, 

PTRSIZE 

}, 

1 Parent", 

"struct Window *", 

5, 

PTRSIZE 

i, 

1 Descendant", 

"struct Window *", 

5, 

PTRSIZE 

}, 

1 (Pointer", 

"USHORT *", 

5, 

PTRSIZE 

}, 

’-PtrHeight", 

"BYTE", 

3, 

BYTESIZE 

}, 

’-PtrWidth", 

"BYTE", 

3, 

BYTESIZE 

}, 

’-XOffset", 

"BYTE", 

3, 

BYTESIZE 

), 

’-YOffset", 

"BYTE", 

3, 

BYTESIZE 

; 


- 1 ; 


int sum, choice 
level++; 

while (choice) { 

sum = SetOptionText(string, structdata, 

(APTR)window, DATASIZE, offset); 
switch (choice = GetChoice(MAXGADG +1)) { 

case 2 : 

if (window->WScreen) 

PrScreen("Screen nel quale è contenuta la 
window", 

window->WScreen); 
break; 
case 3: 

if (window->RPort) 

PrRastPort("RastPort della window", 
window->RPort); 

break; 
case 8: 

if (window->BorderRPort ) 

PrRastPort("BorderRPort della window", 
window->BorderRPort); 

break; 
case 9: 

if (window->FirstGadget) 

PrGadget("Primo gadget nella lista della 
window", window->FirstGadget); 

break; 
case 12: 

printf("Spiacente, non implementato\n\n"); 
break; 
case 10: 

if (window->Parent) 

PrWindow("La window 'parente'", 
window->Parent) ; 

break; 
case 11: 

if (window->Descendant) 
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PrWindow("La window 'discendente'", 
window->Descendant); 

break; 

case MOREGADG: 

PrWindow3("Membri della struttura Window 
(pagina 3)", window, sum); 

break; 


level- 


void PrWindow3(string, window, offset) 
char *string; struct Window *window; int offset; 
{ 

static struct StructData structdata[] = { 


{ 

" IDCMPFlags", 

"ULONG", 

i. 

PTRSIZE }, 

f 

" UserPort", 

"struct MsgPort *", 

5, 

PTRSIZE }, 

{ 

" WindowPort", 

"struct MsgPort *", 

5, 

PTRSIZE }, 

{ 

"(MessageKey", 

"struct IntuiMessage 

*) " 

,5,PTRSIZE} 

! 

"-DetailPen", 

"UBYTE", 

13, 

BYTESIZE}, 

t 

"-BlockPen", 

"UBYTE", 

13, 

BYTESIZE}, 

{ 

" (CheckMark", 

"struct Image *)", 

5, 

PTRSIZE }, 

t 

" ScreenTitle" 

, "UBYTE", 

4, 

PTRSIZE }, 

{ 

"-GZZMouseX", 

"SHORT", 

2, 

INTSIZE }, 

{ 

"-GZZMouseY", 

"SHORT", 

2, 

INTSIZE }, 

{ 

"-GZZWidth", 

"SHORT", 

2, 

INTSIZE }, 

{ 

"-GZZHeight", 

"SHORT", 

2, 

INTSIZE }, 

{ 

" (ExtData", 

"UBYTE *)", 

5, 

PTRSIZE }, 

{ 

"(UserData", 

"BYTE *)", 

5, 

PTRSIZE }, 

{ 

"(WLayer", 

"struct Layer *)", 

5, 

PTRSIZE } 


static char *IDCMPnames[32] = { 

"SIZEVERIFY", "NEWSIZE", 

"REFRESHWINDOW", "MOUSEBUTTONS", 
"MOUSEMOVE", "GADGETDOWN", 

"GADGETUP", "REQSET", 

"MENUPICK", "CLOSEWINDOW", 

"RAWKEY", "REQVERIFY", 

"REQCLEAR", "MENUVERIFY", 

"NEWPREFS", "DISKINSERTED", 

"DISKREMOVED", "WBENCHMES SAGE", 

"ACTIVATEWINDOW", "INACTIVEWINDOW", 

"DELTAMOVE", "VANILLAKEY", 

"INTUITICKS", NULL, 

NULL, NULL, 


NULL, 


NULL, 

NULL, 


NULL, 


NULL, 


"LONELYMESSAGE" 


} ; 


-l; 


int sum, choice = 
level++; 

while (choice) { 

sum = SetOptionText(string, structdata, 

(APTR)window, DATASIZE, offset); 
switch (choice = GetChoice(DATASIZE)) { 

case 1 : 

FlagPrint("Flag IDCMP abilitati in questa 
window", 


IDCMPnames, window->IDCMPFlags); 

break; 

case 2 : " 

if (window->UserPort) 

PrMsgPort("Window->UserPort", 
window->UserPort); 

break; 
case 3: 

if (window->WindowPort) 

PrMsgPort("Window->WindowPort", 
window->WindowPort); 

break; 
case 8 : 

PrString("Titolo dello screen quando questa 
window è attiva", 

window->ScreenTitle); 

break; 


} 

level--; 


Sul prossimo numero: 

• I device handler in dettaglio 

• Analisi del compilatore C Lattice 
5.0 

• I cambiamenti operati nel filing 
System 

• Come tenere sotto controllo la 
memoria di massa 

• Indirizzamento indiretto tramite 
registro 

• ARexx 

• Il linguaggio Assembly su Amiga 

• I dischi di Fred Fish 

• IFF 
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Amiga Prosound Designer 


Un digitalizzatore audio di qualità 


È giunto anche sul mercato italiano, in verità già da un po' di 
tempo, la versione per Amiga del noto digitalizzatore audio 
Prosound Designer della ditta inglese Eidersoft. 

Il prodotto, che era disponibile precedentemente solo per Atari 
ST, può essere acquistato in due forme distinte: hardware e 
software o solamente software. In un primo momento questo 
può sembrare un po' strano, visto che solitamente il software di 
controllo è relativo all’hardware specifico per cui è stato crea¬ 
to. Ciò, in questo caso, è smentito dal fatto che la Eidersoft ha 
incorporato nel proprio programma anche il supporto per unità 
di digitalizzazione di altri costruttori: FutureSound e Perfect- 
Sound. Nel caso che possediate uno di questi digitalizzatori, 
oppure uno di quei cloni piratati che sono disponibili in Italia, 
e non siate soddisfatti del software fornito a corredo, potete, da 
oggi, comprare il software Prosound Designer e mantenere lo 
hardware che avete. Il fatto di poter scegliere tra il software a 
corredo e un’alternativa come il prosound, non può che giova¬ 
re. 

Il manuale è stampato bene ed è anche ben organizzato, visto 
che guida l’utente passo dopo passo all'apprendimento di tutte 
le funzionalità messe a disposizione. Un difetto che si può ri¬ 
scontrare è quello di aver fornito un solo manuale che riguarda 
sia la versione ST che Amiga. Più spesso di quanto si creda, 
può capitare di essere tratti in inganno dal fatto che una spiega¬ 
zione non si riferiva alla propria macchina. Comunque, un let¬ 
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tore attento, non può sbagliarsi poiché le sezioni relative a una 
macchina in particolare sono chiaramente evidenziate da un 
simbolo che non può lasciare dubbi, basta fare un po' di atten¬ 
zione. Sul retro del manuale si trovano le foto degli autori delle 
diverse parti e versioni del Prosound Designer. 

Il digitalizzatore vero e proprio è una piccola unità che si colle¬ 
ga direttamente nella porta parallela dell'Amiga 1000 o, trami¬ 
te un adattatore fornito, nella stessa porta del 500 e del 2000. 
Su un lato si trova l’ingresso per un mini-jack stereo. Sì, il di¬ 
gitalizzatore è stereo e il software supporta completamente sia 
il modo stereo che quello mono. I segnali audio possono essere 
mandati al digitalizzatore da virtualmente ogni sorgente sono¬ 
ra, ma probabilmente la più indicata è un Walkman stereo. Una 
piacevole sorpresa è il fatto che l'adattatore per la porta paral¬ 
lela del 500 e del 2000 è già fornito compreso nel prezzo: in¬ 
fatti se acquistato separatamente può anche costare più di 
30.000 lire. Questo rende più appetibile il pacchetto visto che è 
pronto per essere utilizzato con qualunque Amiga in commer¬ 
cio. 

Il software, per fortuna, non è assolutamente una conversione 
diretta dall'ST ma è stato scritto ex novo per fare uso delle su¬ 
periori capacità sonore dell'Amiga. Dopo aver caricato il soft¬ 
ware da Workbench (veramente delle belle icone, ragazzi) nel 
modo usuale, l'utente passa attraverso una schermata iniziale 
corredata da suoni digitalizzati per poi giungere al pannello di 
controllo. A questo punto, data l'ottima qualità dell'interfaccia 
grafica, la somiglianza con altri software di digitalizzazione 
termina. E stato usato uno splendido effetto 3D per tutti i bot¬ 
toni che servono per selezionare le diverse opzioni. Ciò forni¬ 
sce al prodotto un ottimo aspetto professionale che non si può 
ritrovare in altri software analoghi per funzionalità. 

Alla base dello schermo, che usa tutte le righe messe a disposi¬ 
zione dal PAL, si trovano i bottoni per la modifica della digita¬ 
lizzazione corrente, che è mono oppure è uno dei due canali 
stereo. Le opzioni qui presenti prevedono la possibilità di sen¬ 
tire il brano (play), sentire il brano al rovescio (play back- 
ward), tagliare un sottobrano, cambiare la velocità di 
registrazione e di esecuzione, fondere o sovrapporre più parti. 
Infine sono presenti i selettori per il movimento dei puntatori 
di inizio/fine brano. Nello schermo di Prosound si trovano due 
aree grafiche: una grossa nella parte alta per il monitoraggio in 
tempo reale stereo dell’ingresso (utile per impostare a vista il 
livello di input) e un'altra stretta e lunga posta al centro che 
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mostra ii campione digitalizzato attuale e che serve per com¬ 
piere tutte le operazioni di editing appena menzionate. L'area 
contenente il campione è dotata di due puntatori che possono 
essere utilizzati per indicare una parte di brano su cui si posso¬ 
no poi eseguire una serie di operazioni: esecuzione, salvatag¬ 
gio e modifica. 

Nella parte superiore sinistra dello schermo si trova un piccolo 
pannello che funge da archivio delle digitalizzazioni. I tasti, 
che sono numerati da FI a F8, una volta selezionati con il mou¬ 
se, mostrano un requester che permette di specificare quale 
campione caricare da disco. Quando la digitalizzazione è stata 
caricata il tasto viene, grazie a un effetto grafico basato su un 
uso accorto dei colori, illuminato, a indicare che è un tasto atti¬ 
vo. Selezionando un’altra volta con il mouse lo stesso tasto si 
sentirà il campione appena caricato da disco. Le digitalizzazio¬ 
ni possono anche essere ascoltate usando i tasti funzioni della 
tastiera. Eventualmente si possono attivare più digitalizzazioni 
allo stesso tempo e farle eseguire in un loop continuo, produ¬ 
cendo così, alle volte, ottimi suoni del tipo FX. Se viene cari¬ 
cato un campione stereo, oppure due mono usati come un 
unico canale stereo, quando si seleziona uno dei tasti F per sen¬ 
tire una digitalizzazione, viene automaticamente attivato anche 
il canale associato. Si possono ottenere dei brillanti effetti di ri¬ 
verbero semplicemente spostando leggermente un puntatore di 
un canale rispetto a quello del canale stereo associato. Ogni ca¬ 
nale stereo (destro o sinistro), può essere modificato indipen¬ 
dentemente dall’altro, portando, anche in questo caso, alla 
produzione di effetti sonori strabilianti. Il programma, forse 
non c'era bisogno di dirlo visto che dovrebbe essere uno stand¬ 
ard, salva e carica campioni in formato IFF in modo che non si 
possano avere problemi durante lo scambio di dati con altri 
programmi compatibili IFF. 

Diamo ora un’occhiata ad altre caratteristiche che non possono 
essere trovate in programmi di digitalizzazione paragonabili. 
La funzione zoom, per esempio, è eccellente, soprattutto per¬ 
ché lavora in modo cumulativo. Infatti l’utente può fare ingran¬ 
dimenti e riduzioni come gli pare, fino ad arrivare a vedere 
gruppi di quattro byte. Se si effettua un ingrandimento (o più) e 
si posizionano i puntatori per indicare una certa porzione di di¬ 
gitalizzazione, quando si torna alla riduzione da cui si era par¬ 
titi, i puntatori vengono riallineati nella posizione corretta sul 
grafico compresso. La possibilità di fondere più brani permette 
in pratica di realizzare un eco con numero di ripetizioni e a 
profondità variabile impostabili dall'utente; basta prendere, per 
mezzo dei puntatori, il pezzo di brano di cui si vuole fare l’eco 
e spostarlo verso destra fondendolo ogni tanto con il brano sot¬ 
tostante. 

Nel terzo pannello visibile su schermo (come mai visibile su 
schermo? Leggete più avanti) posizionato nell’angolo supe¬ 
riore destro, si trovano dei bottoni che controllano la registra¬ 
zione e l’esecuzione automatica dei campioni più un gadget 
denominato HI-FI. Quest'ultimo permette di disabilitare, sugli 
Amiga 500 e sui 2000 revisione B, il filtro audio a 7 KHz, ren¬ 
dendo così possibile l’ascolto alla massima qualità, di digitaliz¬ 
zazioni registrate a 14 KHz. Questa è una caratteristica non 
usuale che può realmente fornire qualità HI-FI, purché le digi¬ 
talizzazioni siano più che buone. 
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Inoltre in quest'ultimo pannello si trova un tasto che, quando 
selezionato con il mouse, fa apparire un ulteriore pannello che 
scende dall'alto. Le possibilità che mette a disposizione l’ulti¬ 
mo arrivato sono diverse e tutte molto interessanti; a voi sco¬ 
prire in che situazioni possono essere indispensabili. Per prima 
cosa si può aumentare o ridurre il volume di qualunque palle, o 
eventualmente tutto, di un campione, anche mentre lo si ascol¬ 
ta. Si può anche dimezzare o raddoppiare la frequenza di una 
parte o di tutta la digitalizzazione; utile per ridurre l’occupa¬ 
zione di memoria o per aumentare la qualità, oppure, natural¬ 
mente, per qualche effetto speciale di vostra invenzione. Ci 
sono anche due gadget per salvataggi veloci delle fasi di edi¬ 
ting (per default verso il RAM disk). 

Nel complesso le possibilità di modifica e trattamento dei cam¬ 
pioni sono buone ma c'è sempre spazio per eventuali migliora¬ 
menti. Sicuramente abbiamo tralasciato poche delle possibilità 
più oscure di Prosound Designer, sia perché sono di difficile 
comprensione per i non esperti, sia perché saranno autentiche 
sorprese, che non vogliamo rovinare, per chi utilizzerà a fondo 
il software. Infatti, come per ogni buon prodotto, vi capiterà 
quasi sicuramente di ripetere: "Ehi, non sapevo che avrei potu¬ 
to fare ciò in questo modo!". Prosound è proprio uno di questi 
prodotti. 

Il software è stato scritto non dalla Eidersoft, ma da una ditta 
chiamata Digigraphic, che sta apparentemente lavorando ad al¬ 
tri progetti di Eidersoft, due dei quali sono relativi al Prosound. 
Uno di questi è il Prosound Toolkit che potrebbe essere pronto 
in tempi brevi: si tratta di una collezione di routine audio per i 
programmatori, più qualcos’altro per il miglioramento di digi¬ 
talizzazioni e per conversioni particolari. Il secondo è una ver¬ 
sione Gold (quindi qualcosa di veramente importante) del 
software Prosound. Non si hanno dati certi poiché viene man¬ 
tenuto il più stretto riserbo sull’operazione. 

Non si può che concludere dicendo che il programma ha delle 
ottime caratteristiche e fornisce anche delle prestazioni, per 
certi versi, uniche (evidentemente qualcuno ha passato molto 
tempo a fame un completo debug). Il software è veramente fa¬ 
cile e divertente da usare e può essere veramente interessante 
per gli utilizzatori di altre unità di digitalizzazione. Già, il digi¬ 
talizzatore, quasi ce ne stavamo dimenticando. Ha funzionato 
perfettamente e con diligenza senza provocare nessun proble¬ 
ma. Fa quello che deve fare e ciò dovrebbe bastare. Per essere 
onesti preferiamo il digitalizzatore FutureSound quando si trat¬ 
ta di digitalizzare in mono, per via della presenza di più ingres¬ 
si e per un controllo manuale del livello di ingresso. Sì, la vera 
mancanza del digitalizzatore Prosound (che, non dimentichia¬ 
molo, è stereo), è un potenziometro che regoli li livello di in¬ 
gresso. Un'ultima nota riguardante il prezzo: basta guardarsi in 
giro per rendersi conto che per un prodotto originale, con ga¬ 
ranzia e istruzioni (ahimè, in inglese), è veramente concorren¬ 
ziale per quanto riguarda il prodotto completo, un po’ meno 
per il solo software. 

Il Prosound è acquistabile, in Italia, tramite SoftMail (via Na- 
poleona 16. Como. tei. 031/300174) al prezzo di £ 139.000 per 
il solo software e £ 159.000 per il digitalizzatore più il softwa¬ 
re. 
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Difficoltà e scappatoie 


Alcuni bug, alcuni pensieri e qualche idea 


di Betty Clay 

Esiste un computer senza bug? Ne dubito. Possibile che anche 
una piccola parte di software sia completamente libera da erro¬ 
ri? Probabilmente no. I piccoli errori ci procurano molti pro¬ 
blemi, e quando ne troviamo li correggiamo uno a uno, oppure 
scopriamo la maniera di aggirarli. 

Questo articolo descrive alcune situazioni strane o fastidiose 
che sono state riportate recentemente. Parte di queste derivano 
da esperienze personali, ma la maggioranza ci è pervenuta da 
altre fonti. Le informazioni sono state raccolte da varie reti, ri¬ 
viste, notiziari e discussioni. Forse si riveleranno interessanti o 
utili, sta a voi decidere. 

SETCOMMENT 

Matt Dillon, autore di diversi programmi PD tra cui un famoso 
editor, ha riferito un problema avuto con SetComment nella 
versione 1.3. Sembra che Matt abbia introdotto un commento 
di dimensioni superiori a quelle permesse e il sistema operativo 
lo abbia copiato direttamente sul nome del file e sui campi se¬ 
guenti del blocco di intestazione del file (file header block). 
L’operazione ha provocato un crash spettacolare, che si ripete¬ 
va a ogni riaccensione, e questo fino a quando non è stato eli¬ 
minato il file rovinato. 

Disfarsi di quel file non è comunque stata un'operazione sem¬ 
plice. Il nome del file era distrutto quindi il suo valore di hash 
era sbagliato e così pure il checksum. Avendo un valore di 
hash sbagliato era impossibile cancellare il file. Matt ha usato 
DISKED per disfarsi del file, ma una gran parte degli utenti 
Amiga non ha una conoscenza sufficiente per sbrigarsela da 
solo. 

Ha dato un paio di suggerimenti alla Commodore: (1 ) SetCom¬ 
ment non dovrebbe permettere di scrivere oltre la lunghezza 
prevista e (2) il DiskValidator non dovrebbe solo controllare le 
lunghezze impossibili dei nomi di file, ma dovrebbe anche ac¬ 
certarsi che il valore di hash e il checksum corrispondano. 
Questo è un problema che non possiamo correggere da soli, ma 
possiamo aggirarlo stando attenti alle dimensioni dei nostri 
commenti mentre attendiamo che la Commodore lo risolva. 

Sempre Matt Dillon ha avuto un problema con i file di stampa 


dell’ 1.3 nel Native Developer’s Kit. Ha scoperto che manca un 
XREF in ognuno di questi file, ma Matt dice che se cancellate 
quel riferimento quando appare il messaggio di errore, l'assem- 
bler può continuare senza di esso. 

SPEAK: 

Timothy Meisenheimer ha descritto un problema che ha avuto 
con il device SPEAK: che poi è stato confermato come errore, 
tuttavia si tratta di un bug facile da correggere. 

Gli esempi dati riportano OPT in maiuscole, ma deve essere 
minuscolo per funzionare correttamente. Se solo tutte le solu¬ 
zioni fossero così semplici! 

RESIDENT 

Il "bug" che si trova più frequentemente nella versione 1.3 è 
invece un errore di comprensione. Ci è stato segnalato da di¬ 
verse persone e da parte di tutte le banche di raccolta dati che 
c’è un errore nel UseCount con il comando RESIDENT. 

Per quante volte abbiate usato un comando, spesso mostra un 
UseCount uguale a 0. 

UseCount segnala il numero di task che stanno in quel momen¬ 
to utilizzando un comando, non il numero di task che lo hanno 
usato dal momento dell’avvio. Se non si sta usando alcun task 
in quel momento. UseCount sarà quindi uguale a 0. 

Dischi con Guru 

Un altro problema che continua a causare noie è con i dischi 
che non si riescono a validare. Di solito appare un requester 
con la scritta: Key is out ofrange o key is already set o key is 
already free. Key corrisponde, naturalmente, al numero di set¬ 
tore dell’intestazione del file. 

Se il key è già usato, il settore è considerato da un altro file co¬ 
me sua intestazione, e non possono esistere due file aventi lo 
stesso settore come intestazione. Se il key è troppo grande, si¬ 
gnifica che il sistema operativo ha scritto in un settore il cui 
numero è più grande di 1759 per un floppy, o più grande del 
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più alto numero di settore nella partizione di un hard disk. Ciò 
può essere corretto a mano se siete veramente capaci di usare 
un disk editor, ma di solito si può risolvere più facilmente con 
l'uso di DiskSalv. 

Tale problema il più delle volte è causato da un difetto fisico 
del dischetto, ma può anche essere provocato da uno sbalzo di 
tensione della corrente o da qualcos’altro che disturba il drive 
durante la scrittura. Se vi succede spesso, state probabilmente 
usando dischi che sono vecchi e consunti, oppure di non ottima 
qualità sin dall'inizio o sono dischi a singola facciata. Nel caso 
dei floppy, l’uso di dischi migliori è la miglior soluzione. 

Un altro disco rovinato ha causato un interessante crash sull’A¬ 
miga di Jim Butterfield. Jim ha provato a sostituire un file su 
un disco che era troppo pieno. Sembrava che l'operazione di 
registrazione fosse andata a buon fine, ma quando il disco è 
stato reinserito nel drive la volta successiva, tutto ha funziona¬ 
to bene finché non è stata chiamata una particolare icona. Sullo 
schermo è esplosa una miriade di fuochi artificiali, dai chip del 
suono è uscito un lamento pietoso e la macchina si è bloccata. 

Jim sapeva che a me piace studiare i dischi rovinati e con strani 
problemi, così me lo ha spedito. Esaminando il disco mi sono 
accorta che le dimensioni di quell’icona erano cresciute fino a 
37K di lunghezza e alla fine del file dell’icona (.info file) ho 
trovato il file eseguibile. 

In questo caso, ho copiato i file su un altro disco e ho salvato 
quello rovinato per ulteriori studi. DiskCopy non è utile in casi 
simili poiché copia sia i file sani che quelli contenenti un erro¬ 
re. Il comando Copy, invece, impiega molto più tempo, ma co¬ 
pia solo i file sani. 

File nascosti-1 

C’è un altro problema interessante dato da un disco che non ho 
ancora risolto: non ha dato un Guru e neppure altri segnali di 
allarme. 

Durante la preparazione di un disco mensile per il mio Club 
stavo aggiungendo delle icone a tutti i file utilizzando un pro¬ 
gramma che aggiunge le icone automaticamente. Sul disco c’e¬ 
rano icone di directory di diversi tipi e colori e le ho cancellate 
tutte per poterle sostituire con icone che stessero bene. 

Il programma si è rifiutato di fare nuove icone per le directory, 
allora ho provato a copiare una icona di directory a mano e non 
ci sono riuscita. Quindi ho aperto una directory e non ho più 
trovato nessun file, mi sembrò di aver perso il lavoro di tutta la 
giornata. 

Ero disperata, ho provato a usare l'intero path per richiamare il 
programma e sono così riuscita a caricarlo e lanciarlo. Riusci¬ 
vo a lanciare senza problemi tutti i programmi dei quali mi ri¬ 
cordavo il nome corretto, ma non c’era modo di vedere il loro 
nome né con il comando Dir né con il comando List. 

Se chiamavo una subdirectory di cui mi ricordavo il nome, ap¬ 
pariva normalmente. Ho risolto il problema immediato copian¬ 


do (con il comando Copy e non DiskCopy) i file su un disco 
sano, usando "Copy DFO: to DF1 : all". Sono così riuscita a co¬ 
piare correttamente tutti i file su un nuovo disco dove si com¬ 
portavano normalmente. 

Non so ancora che cosa possa aver causato la perdita di tutti 
quei file sul disco originale. Così ho controllato i file originali 
con un disk editor per diverse volte, ma non ho ancora indivi¬ 
duato niente di strano che possa aver causato questo comporta¬ 
mento. Forse qualcuno di voi potrà aiutarmi a dare una risposta 
a questo mistero. 

File nascosti-2 

Vi è mai successo di non riuscire a cancellare, cambiare il no¬ 
me o comunque modificare un file sul disco che appare ancora 
nella directory? Ogni volta che richiamate la directory riuscite 
a vedere il file, ma qualsiasi cosa facciate non riuscite ad acce¬ 
dere al file. 

La causa di questo è che il puntatore del file si trova nel posto 
sbagliato. 11 puntatore di un file (il numero del blocco di inte¬ 
stazione) deve essere scritto nello slot della directory che corri¬ 
sponde al valore di hash di quel nome del file. Se si trova in un 
blocco diverso il sistema operativo può ancora trovare il nome 
del file e metterlo in una directory, poiché legge il numero di 
settore dal blocco della directory, e poi ottiene il nome del file 
dal settore del blocco di intestazione. 

Fare la cosa inversa è invece un’altra cosa. Quando richiamate 
un particolare file, il sistema prima ottiene il valore di hash del 
nome del file, poi cerca nello slot che corrisponde a quel valore 
il numero del settore dove trova il file. 

Supponiamo che un nome di un file abbia valore di hash 12 
(deve essere tra 6 e 78 compresi). Se il blocco di intestazione 
fosse #898, allora l’accesso alla directory sul disco sarebbe più 
o meno così: 


slot 

0 

1-10 

11 

12 

13 


contenuto 

002 tipo di file 

xxx numero del blocco del file 

che ha valore di hash 11 
898 numero del blocco di 

intestazione del nostro file 
xxx numero del blocco del file 

che ha valore di hash 13 


Dopo aver controllato lo slot numero 12, il sistema legge il 
blocco di intestazione 898, passa allo slot 107 (che è il byte # 
432) e legge il nome del file. Se il numero del settore di inte¬ 
stazione del file si trova nello slot sbagliato, nello slot numero 
12 ci sarà un'informazione sbagliata e non riuscirete a trovare 
il file. 

Il numero potrebbe essere 0, il che indica che non esiste nessun 
file con quel nome; potrebbe trattarsi del numero del blocco 
dove inizia un altro file, e i nomi dei file non corrisponderanno. 
Il sistema controllerà Finterà catena di hash e alla fine si arren- 
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derà poiché non avrà trovato nessun file con il nome giusto. 

In un caso come questo se riuscite a localizzare il file che cer¬ 
cate sul disco, potrete trovare il numero del suo blocco di inte¬ 
stazione all'inizio di ogni blocco e il valore di hash del nome 
del file, e poi mettere quel numero del blocco nello slot che 
corrisponde al nome del file. La maggior parte degli editor di 
dischi vi permettono di cercare una stringa sul disco. Potete 
quindi inserire il nome del file nella stringa da cercare e 1 edi¬ 
tor troverà il blocco di intestazione per voi. 

RAD: 

Molte persone stanno usando RAD: (Recoverable Ram Disk:, 
un RAM disk che non si cancella al reset del vostro Amiga) 
con soddisfazione, eseguendo lo startup dallo stesso ed usando¬ 
lo come WorkBench in memoria. Altri, invece, pensano che 
crei molti problemi. 

Nel mio Amiga c'è qualcosa che dà problemi con qualsiasi 
RAM disk resistente al reset. Penso che RAD: non sia molto 
utile perché ad ogni riavvio riporta un "Read-Write Error" e 
non si disfa dell'errore con un semplice riavvio. Mi dà più pro¬ 
blemi che vantaggi. 

Coloro che invece sono più soddisfatti del RAD: hanno chiesto 
come possono riavviare la macchina dal RAD: anche se hanno 
dimenticato di togliere il disco dal drive. Qualcuno sulla Use¬ 
net (penso fosse Andy Finkel ) ha spiegato come fare. 

Se settate il campo BootPri nella parte di descrizione del RAD: 
del file mountlist a 127, la vostra macchina si avvierà automa¬ 
ticamente da RAD: invece che da disco. Naturalmente a questo 
punto sarà impossibile avviare la macchina dal disco: non po¬ 
tete fare tutte e due le cose contemporaneamente. Beh. impos¬ 
sibile a meno che non usiate prima RemRad:. 

DF1: per l'Amiga 2000? 

Sul 2000 il drive interno è DF0:. ma un drive esterno sarà rico¬ 
nosciuto come DF2:. Molti programmi si aspettano di trovare i 
dischi in DF0: e in DF1 : e non permettono altre configurazioni. 

Questo non è gentile da parte dei programmatori, tuttavia l'u¬ 
tente ha bisogno di aggirare il problema. Se il file MountList 
nella directory devs: ha un elemento che dà il nome di DF1: 
ma ha 2 nell’UnitField (Unit=2) allora l'utente può aggiungere 
la linea "mount DF1:" al file Startup-Sequence e tutti i riferi¬ 
menti al DF1: passeranno al device DF2: risolvendo tutti i pro¬ 
blemi. 

In altre parole il drive esterno risponderà sia a DF1: che a 
DF2:. Ciò rende felice il software. Nella versione 1.3 la Moun- 
tList è già preparata e tutto quello che dovrete fare sarà aggiun¬ 
gere la linea alla Startup-Sequence. 

Per coloro che ancora usano la versione 1.2 (c'è ancora qualcu¬ 
no che lo fà?), il segno "/*" e "*/" dopo il segno "#" devono es¬ 
sere eliminati e bisogna scrivere UN1T=2 e HIGHCYL=79. 


Sostituzione dei drive per il SideCard 

Durante l'estate ho comprato un SideCard per usarlo con il mio 
Amiga 1000. Tuttavia le mie necessità di compatibilità con 
l'IBM sono estremamente limitate e il SideCard è diventato il 
regalo di natale per un parente molto speciale. Era molto felice 
e ha passato molto tempo adattandolo alle sue esigenze, ma il 
terzo giorno il drive ha smesso di funzionare. Abbiamo cercato 
di farlo riparare, ma nei pochi giorni in cui è rimasto ospite da 
me è stato tutto inutile. 

Abbiamo deciso allora di comprare il pezzo di ricambio, ma 
non si poteva sostituire il drive rotto con un Chinon perché non 
erano compatibili. Così abbiamo comprato un Teac, ma anche 
questo non voleva funzionare. Altri amici con più esperienza 
vennero ad aiutarci, ma fu tutto inutile. Il SideCard era perfet¬ 
to, e così pure il drive, ma sembrava che non riuscissero a co¬ 
municare. 

Infine trovammo una soluzione molto semplice: mancava un 
ponticello tra RY e ML. Messo quello il drive funzionava per¬ 
fettamente. Tutto è facile, una volta scoperto il trucco! 

FONT Modificati 

Geoffrey Kim ha segnalato su Usenet un altro bug. Dopo aver 
modificato il font Topaz 8, averlo salvato sotto altro nome nel¬ 
la directory Fonts: e aver cercato di usarlo con FastFonts si è 
trovato di fronte a un messaggio di errore che diceva che non 
poteva usare un font proporzionale, ma il suo font non era pro¬ 
porzionale! 

Questo è successo a causa di un bug della versione 1.2 in FED 
(Font Editor). FED non ripuliva il bit ROMFONT nel campo 
dei flag settando comunque il flag del DISKFONT. FF (Fast 
Font) non accetta un font che abbia settati entrambi i flag. 

E un po' confuso? Forse. Con la versione 1.2 del FED si può 
usare NewZap per correggere questo difetto, ma è più semplice 
procurarsi la versione 1.3. Pare che il nuovo FED abbia risolto 
il problema. 

Il Virus Lazarus? 

Numerose persone (di sicuro dei neofiti nel mondo Amiga) 
hanno recentemente segnalato sia su CompuServe che su Use¬ 
net un nuovo virus. 

Hanno detto che il nuovo virus attaccava quando cercavano di 
recuperare un disco rovinato, sebbene stessero usando il meto¬ 
do approvato dal software di sistema. li disco si rovinava, il 
Requester diceva loro di usare il DiskDoctor per metterlo a po¬ 
sto e loro lo facevano. 

Quando riottenevano il controllo del computer la struttura del 
disco era totalmente cambiata, alcuni dei file mancavano ed il 
nome del disco era cambiato in "Lazarus". Questo non è un vi¬ 
rus, ma è una caratteristica del programma DiskDoctor. 

Che il DiskDoctor qualche volta rinominasse un disco "Laza- 
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rus", mi fu chiaro nel 1985. DiskDoctor mette anche quasi tutti 
i file nella directory principale ed effettua altri cambiamenti 
che proibiscono ogni ulteriore tentativo di recupero. 

E meglio non usarlo sebbene mi abbiano detto che la versione 
1.3 sia molto più affidabile e dice molto di più su quanto sta fa¬ 
cendo ai vostri file. 

Il trucco di cambiare il nome del disco viene fatto quando Di¬ 
skDoctor scopre che la directory principale ha dei problemi, 
specialmente se qualcosa impedisce la lettura del nome del di¬ 
sco. In questo caso viene dato al disco il nome "Lazarus" per 
indicare che è stato fatto resuscitare. 

Malgrado questa operazione, quasi certamente il disco avrà se¬ 
ri problemi. Bisognerebbe copiare immediatamente i file su un 
altro disco e riformattare o buttare via il disco chiamato "Laza¬ 
rus". 

Il virus IRQ 

Un altro virus, e questo è reale, è apparso all'inizio di quest'an¬ 
no. Si tratta del virus IRQ e potrebbe essere il più tremendo di 
tutti quelli finora messi in circolazione. Questo virus è estre¬ 
mamente reale e cattivo. 

Si attacca al primo comando chiamato dalla Startup-Sequence. 
istallandosi al posto del "load hunk" (ndt: la porzione del pro¬ 
gramma che è caricata per prima in memoria e descrive come 
deve essere caricato il resto) e mettendo il vecchio "load hunk" 
nel programma stesso. 

Si manifesta cambiando il titolo della prima schermata con il 
suo nome, IRQ VIRUS. 

Steve Tibbetts ha già fornito un killer per questo virus, ma sarà 
molto difficile evitare che infetti i nostri dischi continuamente. 
Si può attaccare a ogni programma eseguibile. Può trasmettersi 
in file trasferiti da e verso altri computer. 

Il controllo dei file 1.3 

Posso suggerire ai lettori di procurarsi, oltre al killer di Steve, 
una copia del SYSCHECK di Jint Butterfield? (Sarà sul disco 
corrispondente a questo numero di Transactor). 


SysCheck leggerà il vostro disco WorkBench e vi darà 
di tutti i file che sono diversi dalla versione 1.3. 


nome 


Conclusioni 

Un computer senza problemi né stranezze sarebbe molto meno 
interessante, almeno per me, di uno che ne ha poche. In qual¬ 
che modo sembra che queste peculiarità diano una personalità 
alla macchina. Si scoprono in continuazione nuove difficoltà e 
trovare la soluzione a queste ci insegna di più sulla macchina. 
Avete notato che molti stanno ancora trovando strane cose nel 
Commodore 64 dopo tutti questi anni? Quanto sarà allora più 
interessante sfidare tutte le idiosincrasie dell'Amiga! 


(segue da pagina 30) 


Breakpoint 


Beh ... quasi tutti i file. Non controlla la Startup-Sequence, ma 
controlla, invece, tutti i comandi della directory C:, le Librerie, 
i Device, e altri file che difficilmente gli utenti si personalizza¬ 
no. 

Lanciando regolarmente SysCheck con il vostro WorkBench, 
individuerete i file che sono stati contaminati. Possono essere 
sostituiti con gli originali per ripulire la macchina. La combi¬ 
nazione di SysCheck e IRQKiller è la miglior protezione che 
fino ad oggi può essere usata. 


Non ho nulla in contrario allo smanettamento di un computer e 
al condurre esperimenti su di esso. La cosa alla quale faccio 
obiezione è il condurre gli esperimenti senza alcuna idea di 
quali dovrebbero essere i risultati. 

Un altro problema creato dall’esecuzione passo passo di un 
programma senza alcuna idea di come dovrebbero essere i ri¬ 
sultati, consiste nel fatto che veniamo indotti in una sorta di 
compiacimento dalla monotona correttezza della macchina e ci 
lasciamo sedurre credendo che una risposta sbagliata sia giusta. 

"1 è un numero primo, 3 è primo, 5 è primo, 7 è primo....uffa, 
sembra proprio che tutti i numeri dispari siano primi. 9 è pri¬ 
mo, 11 è primo, 13 è primo. YUP, tutti i numeri dispari sono 
primi." 

Se quanto riportato sopra stesse accadendo in realtà e se un fi¬ 
sico stesse esaminando i risultati, si limiterebbe semplicemente 
a scartare il 9 come errore sperimentale. Ma i programmatori, 
oggigiorno, devono essere un po' più cauti. I computer vengo¬ 
no utilizzati in un numero sempre crescente di posti e di appli¬ 
cazioni. Prima o poi un errore software di un computer 
provocherà danni molto seri, magari ucciderà qualcuno! Fac¬ 
ciamo in modo che non sia colpa del nostro programma. 

1 test per eliminare i bug da un software sono possibili, se at¬ 
tentamente studiati e implementati. Vediamo se riusciamo a in¬ 
dividuare le trappole e a evitarle. 

A proposito, quanti di voi hanno notato l'opinione dissenziente 
di Richard Feynman sul disastro del Challenger, in merito alle 
affermazioni ufficiali che la produzione e il test del software 
era Vunica cosa che sicuramente la NASA stava facendo cor¬ 
rettamente? 

Okay... la prossima volta daremo un’occhiata ai debugger più 
tradizionali disponibili su Amiga (a meno che, naturalmente, 
l’Avant-Garde e la Metadigm non rendano disponibili i loro 
nuovi prodotti nel frattempo) e proveremo a suggerire dei me¬ 
todi per migliorare il vostro debugging. 
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Presentiamo in questa 
pagina alcune tra le ultime 
novità disponibili dal ca¬ 
talogo SoftMail. Ecco 
alcune informazioni utili 
per utilizzare il servizio 
SoftMail: è possibile effet¬ 
tuare ordini telefonica¬ 
mente SOLO se è già stata 
effettuata una spedizione a 
proprio nome ed è stata 
regolarmente ritirata. Dal 
secondo in poi accettiamo 
ordini telefonici . Chi desi¬ 
dera notizie sulla disponibi¬ 
lità ed i prezzi dei prodotti 
che non compaiono in 
questa lista può chiamare lo 
(031)30.01.74 dalle 14:30 
alle 1&00. SoftMail può 
organizzare la consegna 
anche_ tramite _ comere : 

interpellateci per maggiori 
informazioni. Oltre alle 
ultime novità qui esposte, 
SoftMail offre Finterò cat¬ 
alogo delle seguenti case: 
Aegis, Cinemaware, EA, 
Microprose, Rainbird, SSI, 
SSG, Sublogic. 


l i è arrivalo il 
catalogo a 
co /ori 
SoftMail? 

Se vuoi 
riceverlo 
grntuitnrm * n/c , 
telefonaci 
subito! 
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telef. 

Coprìtastìera A 500 

25000 

Comiption 

49.000 

Final cartdrige DI 

115000 

Cosmic pirates 

telef. 

Flicker master 

29.000 

Crazy cars 

29.000 

Joy. Slik stick 

15500 

Def con 5 

59.000 

Joy. SpeedKing 

29.000 

Defender of thè crown 

59.000 

Joy. SpeedKing Autof. 

35000 

Deluxe print II 

99.000 

Joy. Tac 2 

29.000 

DigiPaint 

99.000 

Joy. Tac 5 

39.000 

DigiView GOLD 

telef. 

MouseMat tappetino 

22500 

Director 

99.000 

Coprimouse 

20.000 

Disk drive esterno 

299.000 

Port amouse 

12500 

Dos2Dos 

75000 

Portadischi 3" (30) 

34.000 

Dragon’s lair 


Portadischi 5" (40) 

37.000 

(1 MByte, 6 disks) 

75000 

SlimLine (tastiera 64) 

49.000 

Drilier TUTTO kaliano 

59.000 

Voice messenger C64 

60.000 

Dungeon master (1 MB) 59.000 



Elke 

45000 

UBRI/HINTS & TIPS 

Empire 

49.000 



F16Falcon 

59.000 

Alternate city due 


Farkavision 

125000 

specificare 8/16 bk 

15000 

Fire & forget 

39.000 

Bard's tale 1 due 

22500 

Fish 

45.000 

Bard’s tale II due 

25000 

Flight simulator It 

99.000 

Bard's tale NI due 

25000 

Scenery disks 

telef. 

Black cauldron due 

15000 

Galileo 20 

99.000 

Deathiord due 

telef. 

Garfield 

49.000 

Dungeon master due 

25000 

Gauntlet II 

25000 

Elke due 

15000 

Grabbk 

49.000 

Graphic adv. creator flint 7.500 

Hellfire attack 

39.000 

Mars saga due 

telef. 

International soccer 

39.000 

Might & Magic due 

25000 

katy 90 soccer 

39.000 

Pool of radiance de 

25000 

incr.s.sphere 

49.000 

Quest for dues 

39.000 

Jet & Japan bundle 

110.000 

Sentìnel wortd due 

25000 

Joan of Are 

25000 

Starflight due 

25000 

King of Chicago 

49.000 

Ultima V due 

22500 

LED storm 

25000 

Wasteland due 

15500 

Legend of thè sword 

45000 



Life cydes vol.1 

39.000 

AMIGA 


LightlCameralActìonl 

99.000 



Lords of thè Rising Sun telef. 

Heroos lanca /mas disk ta/of. 

Major motìon 

39.000 

Bard's ta/o hints disk 

tahf. 

Maxiplan plus 

299.000 

Aegis draw 2000 

telef. 

Menace 

39.000 

Aegis images 

69000 

Mickey Mouse 

25000 

Aegis impad 

125000 

Modeler 3D 

129.000 

Aegis sonix 

110.000 

Murder on Atlantic 

59.000 

Aegis videotitìler 1.1 

185000 

Nigel Mansell grand prix 49.000 

Alternate reafky: thè city 69.000 

Oblkerator 

45000 

Animatìon muitìpiane 

125000 

Offshore warrior 

39.000 

Armageddon man 

49.000 

Outrun 

25000 

Audiomaster 

85000 

P.O.W. 

59.000 

Audiomaster il 

telef. 

PacMania 

25000 

Baal 

29.000 

Phantom fìghter 

45000 

Barbarìan II 

telef. 

Pioneer piague 

59.000 

Batman 

29.000 

President is missing 

49.000 

Baltlechess 

49.000 

ProSound designer 

79.000 

Black cauldron 

9.000 

ProSound w/hardware 

199.000 

Blitzkrieg at Ardermes 

59.000 

Prowrite 20 

179.000 

Califomia games 

25000 

Publisher plus 

125000 

Carrier command 

49.000 

Reach for thè stare 

59.000 

Celi animator 

telef. 

Re bel . . . Chtckam aliga 

telef. 

Chrono quest 

65000 

Return to Genesis 

39.000 


Rocket Ranger 59.000 

Roger Rabbit 09.000 

SEUCK tele! 

Sex vixens in space 55.000 

Sculpt/Animate 40 telef. 

Sentì nel 49.000 

Sinbad 59.000 

Skyfox II 59.000 

Starfleet 59.000 

Starglider D 49.000 

Superman 39.000 

Swordofsodan 09.000 

The bard's tale II 49.000 

The Works I 249.000 

Three Stooges 59.000 

Tracker 49.000 

TV Sporta: Football 59.000 

Ultima IV 49.000 

Universa! miHtary skn. 45.000 

Data disks 1 e 2 telef. 

Victory road 39.000 

Videoscape 3D 2.0 250.000 

Designs disks telef. 

VIP professional 199.000 

Virus 29.000 

Virus infectìon protectìon89.000 
WB Extras 69.000 

Whiriigig 39.000 

Widow 59.000 

World CI. Leaderboard 25.000 
Zak McKracken 59.000 

Zìng keys 25000 

Zoetrope 199.000 

Zoom 45.000 

3 Demon 145000 


COMMODORE 64 CASS. 


After bumer 18.000 

Barbarìan II 15000 

Barman 15000 

Dragon ninja 15000 

Exploding fist+ 15000 

G.l.hero 15000 

kaly 90 soccer 15000 

Last Ninja II 25000 

MicroSoccer telef. 

Robocop 15000 

R-type 15000 

Serve & volley 22.000 


Shoot'em up consti, kit 25.000 


Stunt bike simulator 5000 

Tiger road 15000 

Total edipse (Hai.) 15000 

4 soccer simulator 15000 


COMMODORE 64 DISCO 

ADD: Heroes of thè lance telef. 
ADD: Pool of radiance 59.000 


American civil war III 49.000 

Barbarìan II 25.000 

Deathiord 35000 

Drilier 29.000 

Echelon (con LipStìck) 59.000 
Eternai dagger 35000 

Fast break 29.000 

Fish 29.000 

Game over l+ll 25000 

GeoPublisher 100.000 

Grand Prix Circuit telef. 

Gulf strike 49.000 

Home video producer 69.000 
ttaly 90 soccer 25000 

LEO storm 15000 

Mars saga 35000 

McArhtu’s war 49.000 

MicroSoccer telef. 

Neurom ancer 39.000 

One on one II 29.000 

Powerplay hockey 29000 

Red storm rising 49.000 

Rocket Ranger telef. 

Shoot’em up consti, kk 35.000 
Stealth mission 75000 

T.K.O. 29.000 

The bard’s tale HI 35000 

Total edipse (Hai.) 20.000 

Ultima V 49.000 

Wasteland 39.000 

Wec Les Mans 21.000 

Who framed Roger RabbH telef. 
Zak Me Kracken 39.000 

4 soccer simulator 25000 

COMMODORE 128 DISCO 
(128K.80C0L) 

“C” Larrguage 99.000 

Basic 50 75000 

GE0S128 telef. 

Mach 128 125000 


-OFFERTE specìali 

(FINO AD ESAURIMENTO) 

FIRBBIRD SPECIAL 

Valore A «ole 

AMIGA Bibbie Bobble+Wbirligig+ 
Enlightenmeot 

107.000 75.000 

C64 «a»». Savagc + Iatearity+Scattaci 

4S.OOO 33.000 

C64 dùco Savage -f Intemity+Sentinel 

65.000 39.000 

AEGIS ENTERTAINMENT 

AMIGA Arazok't Tomb+Port* of Cali 

120.000 S9.000 

DEFENDBR OF THE CROWN C64: ca»«. 12.000 duco 15.000 

... SOFTMAIL TI DA’ DI PIU’. 



BUONO D’ORDINE da iaviare a: LAGO DIVISIONE SOFTMAIL, VIA NAPOLEONA 16, 22100 COMO, FAX (031) 30.02.14, TEL (031) 30.01.74 


Deriderò ricevere i icgaeati artìcoli: 

□ Addebitate l'importo ralla mia CARTASI/MASTERCARD/VISA/AMERICAN EXPRESS or. 

□ Pagherò al portico ia coatranegao 


Titolo del prograa 


Compì ter 


ORDINE MINIMO LIT. 20.000 (SPESE ESCLUSE) 


Cognome e tome 

ladirizzo_ 

CAP 


teadeaza 


Città 


Prov. 


FIRMA (SE MINORENNE QUELLA DI UN GENITORE) 
VERRANNO EVASI SOLO GLI ORDINI FIRMATI_ 


Cauetta/dirco/acceriorio 


Prezzo 


Coatribato rpere di rpedizioae Lit 
TOTALE LIT. 


S.000 


_Nr. 

Telefono 


-K- 
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I device di Amiga - 2 


Come usare i device di Amiga nei vostri programmi 


di Steve Simpson 


Steve Simpson lavora come consulente programmatore per 
Amiga e IBM PC. Negli ultimi cinque anni ha vissuto in Svezia, 
lavorando come traduttore di documentazione tecnica. Si inte¬ 
ressa attivamente dello sviluppo di utility DOS. di sistemi e del 
controllo di processi industriali; attualmente sta sviluppando 
alcune routine per il SideCar. Steve è anche l'autore di Di- 
skRepair, una utility che recupera il contenuto di dischi dan¬ 
neggiati. 

Chiunque abbia esplorato le possibilità offerte da Amiga nel 
campo deiri/O conoscerà certamente i device di Amiga. 

I device di Amiga si trovano in forma di file (con il suffisso 
.device) nella directory Devs sul disco di boot oppure sono già 
contenuti nella ROM del Kickstart. Il concetto di device è alla 
base dell’architettura di I/O "device independent" di Amiga 
(N.d.T.: "device independent" significa indipendente dal dispo¬ 
sitivo con cui si intende colloquiare) e offre una forma di inter¬ 
facciamento "omogeneo" tra il sistema e il mondo esterno. 

Questo articolo è il secondo di una serie sull'argomento e deri¬ 
va da un progetto al quale l’autore si è interessato; l’intento è 
di descrivere come un device di Amiga possa essere creato e 
aggiunto a quelli già presenti nel sistema. Dal momento che 
sussistono parecchie somiglianze tra device e library, può esse¬ 
re utile che prima leggiate l’articolo "Come creare delle run-ti- 
rne library", presente nel numero scorso, per avere un'idea di 
come viene implementata una library su Amiga. 

Che cos'è un device? 

Un device fornisce la possibilità di rendere le procedure di I/O 
indipendenti dal dispositivo interessato; il suo scopo è quello di 
fornire un interfacciamento standard tra sistema e mondo ester¬ 
no e di rendere questo interfacciamento trasparente al sistema. 
Queste caratteristiche devono valere per tutti i dispositivi e per 
far questo è necessario che per ognuno di essi sia sempre di¬ 
sponibile un certo numero di funzioni e strutture standard, co¬ 
muni a tutti i dispositivi. 


Questo è il meccanismo con il quale sono stati realizzati i devi¬ 
ce correntemente usati su Amiga, come il trackdisk.device, il 
console.device, l’input.device, il gameport.device e l’audio.de¬ 
vice (che sono residenti in ROM) e il parallel.device, il se¬ 
rial.device, il printer.device e il clipboard.device (che invece 
vengono caricati in memoria da disco quando richiesti dal si¬ 
stema). 

La struttura di un device 

Dal punto di vista della struttura, un device è molto simile a 
una run-time library di Amiga. La struttura Device è definita 
nel file "include" exec/libraries.h nella maniera seguente: 

struct Device 
{ 

struct Library dd_Library; 

1 ; 

Così come una libreria, un device consiste di una tavola di in¬ 
dirizzi a cui saltare seguita da un nodo libreria e da informazio¬ 
ni varie, zona che è a sua volta seguita da un’area dati. 

Il trackdisk.device è disposto nella seguente maniera (ricorda¬ 
tevi che gli indirizzi indicati potrebbero differire da quelli pre¬ 
senti nella vostra macchina): 


offset 

FFDC ( 

-36) 

JMP 

$00FEA06A 

AbortIO 

FFE2 ( 

-30) 

JMP 

$00FE9FBE 

BeginlO 

FFE8 { 

-24) 

JMP 

S00FEA06A 

ExtFunc 

FFEE ( 

-18) 

JMP 

$00FE9F14 

Expunge 

FFF4 ( 

-12) 

JMP 

500FE9F92 

Close 

FFFA ( 

-6) 

JMP 

$00FE9F42 

Open 

0000 


Nodo 

• library - 

f lags 


- versione 

- checksum 

- numero di aperture 

Area Dati 


Un dispositivo, d’altro canto, richiede anche routine specifiche 
e queste vanno opportunamente inserite nel contesto della defi¬ 
nizione del device. 


Ancora nello stesso modo delle library, la tavola cresce verso il 
basso nella memoria (a partire dal nodo library, in questo caso) 
e l’ordine dei suoi elementi rimane invariato: cambiano solo le 
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destinazioni dei salti, che dipendono da dove l’AmigaDOS ha 
caricato le routine del device. 

Se il registro A6 contiene un puntatore alla struttura Device de¬ 
siderata, l’istruzione assembler: 


JSR 


-30(A6) 


JSR 


LVOBeginlO(A6) 


LIBINIT 
LIBFUNC 
LIBFUNC 
LIBFUNC 
ecc. 


Dev_BeginIO 
Dev_AbortIO 
Dev Fune 


dove LIBINIT definisce gli offset relativi alle routine standard 
di una library (cioè quelli di Open, Close. Expunge e ExtFunc). 
Per saltare alla funzione Dev_Func si potrebbe dunque impie¬ 
gare l’istruzione: 


LINKLIB 


Dev Func,A6 


dove, come al solito, supponiamo che A6 contenga il puntatore 
alla struttura Device. 

Oltre alla consuete funzioni Open(), Close(). ExpungeO, e Ext- 
FuncO, che sono le routine che costituiscono il nocciolo di una 
library, in un device devono essere presenti due funzioni ag¬ 
giuntive. BeginlOO e AbortIO(). 

BeginlOO è la routine di impiego generico per IT/O presente 
in tutti i device; come ingresso richiede un puntatore alla strut¬ 
tura lORequest. che contiene le informazioni concernenti la ri¬ 
chiesta di I/O in questione. 

La definizione della struttura lORequest è presente nel file 
exec/io.h ed è qui riportata per comodità: 

struct lORequest 
I 


struct 

Message 

io Message; 

struct 

Device 

*io Device; 

struct 

Unit 

*io Unit; 

UWORD 


io Command; 

UBYTE 


io Flags; 


BYTE 

1 ; 


io Error; 


comporterebbe l’esecuzione della funzione BeginlO. In assem¬ 
bler, l’offset può essere dichiarato come un valore globale nel 
file sorgente (con il prefisso _LVO) o definito come una co¬ 
stante nel file .i opportuno. Se _LVOBeginIO è definito come 
-30 ($FFE2), la funzione BeginlO può essere chiamata anche 
in questa maniera: 


Se il device ha anche funzioni che possono essere chiamate 
senza passare attravero BeginlO, allora i loro offset possono 
essere ottenuti dalla posizione che le istruzioni di salto ad esse 
relative occupano dopo quelle relative alle funzioni standard 
del device. In assembler, questo si traduce nella definizione se¬ 
guente: 


I membri della struttura hanno il seguente significato: 

ioMessage: contiene una struttura Message nella quale sono 
presenti informazioni associate alla struttura lORequest stessa 
che vengono usate sia per comunicare al device il completa¬ 
mento delFI/O sia internamente per soddisfare secondo un ben 
preciso ordine le varie richieste. 

io Device: puntatore alla struttura Device associata alla richie¬ 
sta di I/O in questione. Questo membro viene predisposto dal 
device all’apertura. 

io Unit: puntatore alla struttura Unit associata all’unità in que¬ 
stione del device. Anche questo membro è inizializzato dal de¬ 
vice stesso all’apertura. 

io_Command: il tipo di comando richiesto; può essere sia un 
un comando standard sia uno specifico del device. 

io_Flags: impiegati per specificare particolari opzioni o per 
precisare lo stato del device. 

io_Error: il numero d’errore restituito al completamento delle 
operazioni richieste. 

I comandi possono essere sia standard e quindi comuni a tutti i 
device, sia peculiari del device. I comandi standard, come "re- 
ad" e "write”, vengono eseguiti da tutti i device per i quali un 
comando simile abbia senso, mentre i comandi specifici del de¬ 
vice sono riconosciuti ed eseguiti solo da un ben particolare 
device; un esempio di quest'ultima classe di comandi è la ri¬ 
chiesta di allocazione di un canale all’audio device. 

I comandi standard sono i seguenti: 

CMDCLKAR: azzera tutti i buffer interni al device. 

CMD FLUSH: chiede al device di interrompere tutte le ri¬ 
chieste di I/O in corso di esecuzione e quelle che sono ancora 
in attesa. A tutte le richieste viene risposto con un codice di er¬ 
rore. 

CMDINVALID: dice al device che il task che ha effettuato 
la richiesta ha mandato un comando non valido. 

CMD_READ: richiede il trasferimento di un certo numero di 
byte di dati dai buffer interni al device a quello specificato dal 
programma chiamante. 

CMD RESET: riazzera il device (solo l’unità specificata) e le 
routine ad esso interne. Tutti i comandi in attesa di esecuzione 
sono persi. 

CMD_STOP: blocca immediatamente il comando in corso di 
esecuzione. Le richieste che eventualmente arrivino nel frat¬ 
tempo sono poste in una lista di attesa. 
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CMD_UPDATE: richiede il trasferimento di tutti i dati pre¬ 
senti nei buffer interni al device al dispositivo fisico di I/O. 
Questo comando fa sì che non rimangano dati nei buffer interni 
che non siano ancora stati trasferiti a destinazione. 

CMD WRITE: trasferisce un certo numero di dati dal buffer 
del programma chiamante nei buffer del device. 

Tutti i comandi standard sono individuati da valori definiti nel 
file exec/io.h; alla lista appena presentata si possono aggiunge¬ 
re i comandi specifici del device. 

AbortlOQ richiede come argomento un puntatore alla struttura 
lORequest e tenta di abortire dalle precedenti richieste di I/O. 
Questa funzione torna utile per cancellare anche tutte le richie¬ 
ste ancora in lista d'attesa. 

È possibile aggiungere altre routine nella definizione del devi¬ 
ce; tali routine risulteranno associate al device. Per far questo 
si aggiungono, nella tabella che precede la struttura Device, ul¬ 
teriori istruzioni di salto, oltre a quelle consuete per un device. 
Tali istruzioni devono ovviamente trasferire il controllo al co¬ 
dice relativo a tali routine aggiuntive. Un esempio è fornito 
dalla funzione RawKeyConvertQ, che fa parte del console.de¬ 
vice. 

Le modalità operative 

Un device può, all'apertura, lanciare uno o più task ed avere 
quindi uno o più "task control block" associati. Ogni task pos- 
siederà un proprio message port in modo da consentire il man¬ 
tenimento in una lista di attesa delle richieste di I/O che gli 
pervengono. La struttura lORequest può essere vista come un 
tramite per inviare messaggi ai task che hanno la funzione di 
device. Non appena la richiesta associata a un messaggio viene 
soddisfatta, il device risponde al programma chiamante, resti¬ 
tuendo la struttura lORequest. Alla luce di queste considera¬ 
zioni, BeginlOO, SendlOQ e DoIOQ divengono nient'altro che 
applicazioni speciali del meccanismo di "message passing" di 
Amiga. 

Il controllo dell T/O mediante device può essere sia sincrono 
sia asincrono. La funzione BeginlOQ realizza la modalità sin¬ 
crona, che è anche la più semplice; BeginlOQ viene chiamato 
con una struttura lORequest opportunamente inizializzata e 
non restituisce il controllo fino al completamento dell'opera¬ 
zione richiesta. Il programma chiamante sarà. cioè, posto in 
stato di attesa fino alla restituzione della struttura lORequest. 
che conterrà un codice d'errore oppure zero. Un device che 
operi in modalità sincrona non ha necessariamente dei task 
control block (relativi a sub-task) ad esso associati. 

Il controllo asincrono richiede che il device abbia almeno un 
task con relativo message port associato. In tali condizioni, il 
device è in grado di offrire la possibilità di un controllo sia 
asincrono sia sincrono, con la gestione della lista di attesa di¬ 
pendente dalla particolare implementazione del device. A se¬ 
conda dello stato del task status flag del device, il messaggio 
relativo alla richiesta di I/O viene immediatamente inviato al 
task o inserito nella lista di attesa del message port. Il device 


prende in considerazione le richieste di I/O che così si accumu¬ 
lano col criterio FIFO. ovviamente. Il programma chiamante 
può allo stesso modo aspettare la risposta (I/O sincrono) o an¬ 
dare avanti e fare qualcos’altro nel frattempo (I/O asincrono). 
Un esempio di un task di device è quello dei task lanciati, uno 
per ogni unità del trackdisk.device (e di unità del trackdisk.de- 
vice ce n'è una per ogni disk drive presente nel sistema). 

Le Unità di un device 

A ogni device possono essere associate diverse strutture Unit; 
tali strutture sono definite nel file exec/devices.h nella maniera 
seguente: 


struct Unit 
1 

struct MsgPort 

UBYTE 

UBYTE 

UWORD 


*unìt_MsgPort; 
unit_Flags; 
unit_pad; 
unit._OpenCnt ; 


Il significato dei membri di questa struttura è il seguente: 

unit_MsgPort: puntatore al message port del task associato al¬ 
l'unità. 

unit Flags: flag relativi alla lista d’attesa e al controllo del 
task. 

unit_OpenCnt: numero di volte che questa unità è stata aper¬ 
ta. 

La struttura Unit viene inizializzata dal device per ognuna del¬ 
le unità aperte e un puntatore ad essa viene messo in un mem¬ 
bro opportuno della struttura lORequest. Il numero dell'unità 
viene specificato come parametro quando si chiama la funzio¬ 
ne OpenDeviceQ; tale numero può riferirsi a un’unità fisica o a 
un altro task di device. Per esempio, ogni disk drive viene con¬ 
siderato come un'unità a sé stante dal trackdisk.device; in pa¬ 
role più semplici, questo significa che è uno stesso programma 
ad occuparsi delle varie unità dischi, ma che ogni unità ha un 
proprio task control block, un proprio message port e proprie 
aree dati. 

Altre strutture di richiesta di I/O 

Tra quelli di sistema, solo i device audio, printer e timer impie¬ 
gano la struttura lORequest prima descritta. Gli altri device 
usano una sua estensione, la struttura IOStdReq. definita nel fi¬ 
le exec/io.h: 

struct IOStdReq 


struct 

Message 

io_Message; 

struct 

Device 

*io Device; 

struct 

Unit 

*io Unit; 

UWORD 


io Command; 

UBYTE 


io Flags; 

BYTE 


io Error; 
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ULONG 
ULONG 
APTR 
ULONG 
ULONG 
ULONG 
} ; 


io_Actual; 
io_Length; 
io_Data; 
io_Offset; 
io_Reservedl; 
io Reserved2; 


io_Actual: il numero di byte effettivamente trasferiti nell’ope¬ 
razione di I/O richiesta. 

ioLength: il numero di byte di cui è stato richiesto il trasferi¬ 
mento. 

io_I)ata: puntatore al buffer dei dati del programma chiaman¬ 
te. 

io_Offset: la spefica di allineamento (per i device, come il 
trackdisk.device, che la richiedono). 

io_Reservedl: riservato per eventuali espansioni della struttu¬ 
ra. 

ioReservedl: riservato per eventuali espansioni della struttu¬ 
ra. 

Un certo tipo di device può richiedere un’estensione della 
struttura IOStdReq o della lORequest. Ad esempio, il track¬ 
disk.device usa una struttura IOExtTD per ospitare importanti 
informazioni aggiuntive: 


struct IOExtTD 
{ 

struct IOStdReq 

ULONG 

ULONG 


iotd_Req; 
iotd_Count; 
iotd SecLabel; 


in cui: 

iotd_Req: è la struttura IOStdReq appena definita. 

iotd_Count: conta il numero di estrazioni del disco. 

iotd_SecLabel: è un puntatore a un buffer di 16 byte in cui 
vengono messe informazioni relative alla "sector label" del di¬ 
sco. 

La struttura IOStdReq contiene al suo interno la lORequest co¬ 
me una sottostruttura ed è principalmente usata per restituire 
dati al programma chiamante; come regola di validità generale, 
si deve tener presente che il primo membro di una struttura, per 
così dire "personalizzata" per un device creato dall'utente, de¬ 
ve essere una struttura lORequest o IOStdReq. 

Come inviare le richieste di I/O 

Le richieste di I/O possono essere inviate ai device tramite le 
seguenti funzioni: 


BeginIO(): invia al device la richiesta di I/O; il controllo può 
essere asincrono o sincrono, a seconda deH’implementazione 
del device. 

DoIO( ): invia la richiesta di I/O e attende il termine delle ope¬ 
razioni specificate prima di restituire il controllo al programma 
chiamante (caso sincrono). 

SendlOl): invia la richiesta di I/O e restituisce immediatamen¬ 
te il controllo al programma chiamante, anche se non ha avuto 
luogo alcun trasferimento (caso asincrono). 

AbortlOO: tenta di interrompere una richiesta di I/O fatta in 
precedenza. 

WaitlOO: è usata per attendere il completamento delle opera¬ 
zioni associate a una richiesta asincrona di I/O. Il controllo non 
viene restituito sino al soddisfacimento della richiesta di I/O. 

CheckIO(): è usata per controllare se una certa richiesta asin¬ 
crona di I/O sia stata soddisfatta o meno. 

DoIO(), SendIOO. WaitlOO e CheckIO() sono funzioni dell’E- 
xec e pertanto fanno parte della exec.library, mentre BeginlO() 
è parte costitutiva della definizione del device; AbortlOO, in¬ 
vece, è definita tanto nel device quanto nella exec.library. 

QuickIO 

La modalità QuickIO rappresenta una scorciatoia che permette 
di evitare la lista di attesa che si forma al message port del de¬ 
vice. Con il flag IOF_QUICK si fa presente al device che il 
programma vuole che 1 ’ I/O avvenga subito. Nel caso in cui ciò 
sia possibile, il device esegue quanto richiesto e comunica il ri¬ 
sultato al programma chiamante. Sotto QuickIO il device non 
invia un messaggio di risposta al programma chiamante. Se un 
device non ha un proprio task allora la modalità QuickIO non 
comporta alcuna variazione rispetto alla situazione consueta. 
L’effettivo comportamento del device in modalità QuickIO di¬ 
pende comunque dalla specifica implementazione del device 
stesso. 

La funzione SendIOO si avvale del flag IOF_QUICK, ritornan¬ 
do al programma chiamante prima che la richiesta sia stata 
soddisfatta. DoIOQ, al contrario, azzera tale flag e poi chiama 
WaitlOO per attendere il completamento dell’esecuzione della 
richiesta. Entrambe le funzioni comunque inviano la richiesta 
al device tramite la routine BeginlOQ (che, lo ricordiamo, è 
parte integrante del device). 

Ancora sulle Unit 

Abbiamo visto che un’unità di un device è costituita da niente 
altro che un puntatore a un "task control block" (TCB) ovvero 
al message port di un task. A seconda del tipo di device, ci pos¬ 
sono essere una o più unità e ognuna ha un TCB ad essa asso¬ 
ciato; in questa maniera ogni unità di un device consente la 
gestione di una lista di attesa di richieste di I/O. separata dalle 
altre. La possibilità di avere più unità è ovviamente sfruttata a 
livello di sistema; il timer device ha, infatti, due unità, l’audio 
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device ne ha quattro e il console device può invece averne un 
numero illimitato. 

In definitiva, tutte le richieste, tanto sincrone quanto asincrone, 
giungono all'unità attraverso la funzione BeginIO(); questa 
funzione può chiamare direttamente la funzione ExecutelOO, 
se è richiesta la modalità QuickIO, o può inserire la richiesta 
nella lista di attesa del message port dell’unità prescelta. 

Il task relativo all'unità, quando rimuove una richiesta di I/O 
dalla lista del message port. passa alla routine ExecutelOO il 
puntatore alla struttura IORequest rimossa e un puntatore alla 
struttura Device interessata. A questo punto, il task alza un flag 
che fa in modo che altre eventuali richieste siano poste in lista 
d’attesa fino al completamento della richiesta in corso di ese¬ 
cuzione. La funzione ExecutelOO individua l’indirizzo della 
funzione associata al comando nella tabella dei comandi 
(cmdTable) e salta a tale locazione; dopodiché, quello che ac¬ 
cade dipende strettamente dal tipo di device, ovviamente. 

Al termine dell’esecuzione del comando, il controllo viene 
passato a Terminatelo! ), che azzera i flag della unità e rispedi¬ 
sce la struttura IORequest al programma che l’aveva inviata, 
con una chiamata alla funzione ReplyMsgO. 

Le routine di un device 

Le routine presenti in un device si dividono in due categorie 
principali: i comandi, cioè le routine che vengono eseguite in 
risposta a una richiesta di I/O, e le funzioni, alle quali si acce¬ 
de, come per le funzioni di una library, attraverso un offset re¬ 
lativo all’indirizzo base della struttura Device. Le funzioni e i 
comandi possono essere scritti indifferentemente in assembler 
o in C; devono, comunque, essere dichiarati come oggetti 
esterni (in assembler, con XREF <nome funziono) nel sor¬ 
gente della parte principale del device, in modo che possano 
essere individuati correttamente dal linker. 

Ai comandi, che poi sono le routine che effettuano le vere e 
proprie operazioni di I/O. è associato un puntatore nella tavola 
dei comandi del device. Il membro io_Command della struttu¬ 
ra IORequest specifica quale comando eseguire. Generalmente 
i parametri vengono passati alle routine attraverso i registri e 
queste si occupano di aggiornare opportunamente i campi 
io_Actual e io_Error della struttura IORequest prima di resti¬ 
tuire il controllo. 

Nel caso in cui voleste scrivere dei comandi in C. ricordatevi 
che è necessario andare a pescare i parametri nei registri e tra¬ 
sferirli nell'ordine corretto sullo stack dove una routine scritta 
in C si aspetta di trovarli. 

Le funzioni possono essere usate per predisporre delle modali¬ 
tà di funzionamento del device o per usufruire di particolari 
possibilità messe a disposizione da un certo device (come, ad 
es„ RawKeyConvertO nel console.device). Alle funzioni di un 
device si accede nella stessa maniera in cui si accede alle fun¬ 
zioni di una library: per poterle implementare in C, è necessa¬ 
rio servirsi di una "interfaccia" (finora obbligatoriamente 
scritta in assembler, ma che, con alcune nuove release dei com¬ 


pilatori, potrà essere scritta direttamente in C), che si occupi di 
trasferire i parametri dai registri sullo stack nel giusto ordine e 
che poi chiami la routine C che costituisce la funzione vera e 
propria. Inoltre, per accedere a tali funzioni da C, risulta neces¬ 
sario scrivere un'altra interfaccia, usata al momento del lin¬ 
king, individuata dal nome della funzione in questione e che ha 
il compito di passare il controllo all'istruzione di salto corri¬ 
spondente alla funzione prescelta nella jump-table del device. 

Come allestire un device 

Le varie parti che vanno a comporre un device vengono compi¬ 
late senza il consueto modulo di startup (.begin per chi usa il 
Manx e c.o per chi usa il Lattice C) dal momento che esso ri¬ 
sulta inappropriato per l’uso che intendiamo fare del codice. 
Durante la compilazione o l’uso dell’assembler. è opportuno 
impiegare le opzioni "large code" e "large data"; inoltre, è buo¬ 
na norma che il nome del file che costituisce il device abbia il 
suffisso ".device". 

La struttura Device che abbiamo prima considerato può essere 
estesa. Nell'esempio di device che segue l'articolo, alla struttu¬ 
ra Device facciamo seguire un certo numero di puntatori e di 
flag che sono frequentemente usati nel contesto del device. In 
C, la struttura usata nel device di esempio potrebbe essere così 
definita: 

struct MyDev 
{ 


struct 

Device 

md Device; 

struct 

ExecBase 

*md ExecBase; 

struct 

DosBase 

*md DosBase; 

ULONG 


md SegList; 

UBYTE 


md Flags; 

UBYTE 


md pad; 

struct 

}; 

Unit 

*md_units[MD NUMUNITS 


md_Device: la struttura Device associata al device. 

md_ExecBase: puntatore alla exec.library. 

md DosBase: puntatore alla dos.library. 

mdSegList: puntatore BCPL alla "segment list" del device. 

md_Flags: flag impiegati nel device. 

mdunits: array di puntatori alle unità del device. 

Il nostro esempio di device 

Il ROM Kernel Manual: Libraries and Devices (RKM) presen¬ 
ta un esempio di come creare un device, ma gli svariati errori 
che compaiono nel listato rendono tale esempio virtualmente 
inutile ai fini pratici. 

11 listato mydev.asm (listato 3), insieme con i moduli di sup¬ 
porto mydev_def.i (listato 1 ) e asmsupp.i (listato 2), fornisce il 
codice per un device (device che questa volta, invece, funzio- 
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na!). L'esempio del RKM, una volta individuati gli errori che 

10 costellano, è servito solo come traccia. 

Una gran parte dei dettagli implementativi di un device sono 
identici a quelli di una run-time library: c'è, comunque, un'im¬ 
portante differenza nella "function table" o funcTable, come è 
chiamata nel file mydev.asm, che contiene gli indirizzi assoluti 
delle routine del device. L'ordine di tali indirizzi è importante: 
infatti, gli indirizzi delle funzioni scritte dall'utente devono ap¬ 
parire dopo l'indirizzo relativo alla funzione AbortIO(). La ta¬ 
vola è terminata da un -1L. 

L’interfaccia con il sistema 

Un device di Amiga deve comprendere un insieme minimo di 
6 funzioni standard: Open(), Close(), ExpungeO, ExtFuncQ, 
BeginIO() e AbortlOO. I riferimenti a OpenDeviceO, CloseDe- 
vice() e RemDevice() vengono tradotti ripspettivamente in 
chiamate a Open(), Close() e RemDeviceO mentre un riferi¬ 
mento a BeginlOO, DoIO() o SendIO() coinvolge la funzione 
BeginlO definita nel device. 

DoIO(), SendIO() e BeginIO() sono funzioni definite nella so¬ 
lita link library (amiga.lib); BeginlOO, in particolare, non è al¬ 
tro che un semplice modulo di interfaccia alla routine BeginlO 
del device. 

Come installare un device 

11 listato 4, add_dev.c, illustra come procedere per rendere di¬ 
sponibile al sistema un device. Il device viene caricato in me¬ 
moria da LoadSegO. dopodiché una chiamata a MakeLibraryO 
inizializza la jump-table del device, predispone le aree dati ed 
esegue le routine di inizializzazione eventualmente fomite dal¬ 
l’utente. 

Gli argomenti della funzione MakeLibraryO comprendono un 
puntatore alla tabella degli indirizzi delle routine del device e 
alla tabella di inizializzazione dei dati, un puntatore alla routi¬ 
ne di inizializzazione del device, il numero di byte richiesti dal 
device, nonché il puntatore BCPL restituito da LoadSegO. Il 
numero di byte di memoria richiesto è quello che serve per al¬ 
loggiare la struttura del device e la zona dati. 

Con l’istruzione 

AddDevice(myDevice); 

si aggiunge la struttura Device puntata da myDevice nella lista 
di device gestita da Exec, rendendo in questa maniera disponi¬ 
bile il nuovo device ai vari programmi applicativi che possono 
averne bisogno. C’è anche un altro mezzo per installare un de¬ 
vice nel sistema. Si può salvare il device nella directory logica 
DEVS:, cioè dove il sistema va a vedere quando non trova nel¬ 
le liste di sistema il device richiesto con OpenDeviceO. Se il 
device richiesto viene trovato, il sistema operativo lo carica in 
memoria e lo inizializza automaticamente; affinchè tutto fun¬ 
zioni correttamente, però, il device deve essere strutturato nella 
maniera illustrata nel listato mydev.asm. 



L’impiego di un device 

E necessario seguire una certa procedura prima di accedere alle 
funzioni e ai comandi messi a disposizione da un device. 

Prima di richiedere l’apertura del device, infatti, bisogna predi¬ 
sporre un message port attraverso il quale avverrà il dialogo 
con il device stesso e allocare la struttura IOStdReq o una sua 
estensione. Vediamo in maggior dettaglio i passi necessari per 
l'uso di un device. 

• II device abbisogna di un message port per restituire le 
strutture di richiesta I/O con i codici d’errore o altre utili 
informazioni. Per creare questo port potete far ricorso alla 
funzione CreatePort() definita in amiga.lib. 

• Il device può impiegare la struttura IORequest o IOStdReq 
oppure una specifica per un particolare uso. Nel caso in cui 
si usino le strutture standard, ci si può rivolgere a funzioni 
definite nella link library amiga.lib, che sono Create- 
StdIO() e CreateExtIO() e che si occupano di allocare ed 
inizializzare correttamente tali strutture. 

• Per avere accesso alle funzioni e ai comandi si può ora 
chiamare OpenDeviceO. Si ricordi che un device può con¬ 
sentire che coesistano più unità distinte. 

• Al termine del programma che usa il device, non ci si di¬ 
mentichi di chiamare CloseDevice(), di liberare tutta la 
memoria allocata per le strutture relative all’I/O e di rila¬ 
sciare il message port. A tale scopo si usano le funzioni 
DeleteStdIO(), DeleteExtlOO e DeletePort(). 

Il listato 5 (main.c) mostra come procedere per eseguire corret¬ 
tamente le inizializzazioni richieste; in particolare, ci sono 
esempi di invio di richieste di I/O e di chiamate alle funzioni 
del device. Nel modulo di interfaccia devfunc.asm (listato 6) si 
illustra nel dettaglio come accedere alle funzioni del device. 

Uso dei registri 

Un certo numero di registri sono convenzionalmente riservati 
per scopi particolari. Il registro A6 contiene un puntatore alla 
struttura Device (o Library), mentre AO e Al sono generalmen¬ 
te usati per passare gli argomenti a una funzione, il cui risultato 
è poi posto in DO e DI. AO, Al, DO e DI possono essere consi¬ 
derati come registri di lavoro e il loro contenuto può non essere 
conservato durante l’esecuzione delle routine. 

Conclusione 

Tutte le richieste di I/O sono trattate dal sistema fondamental¬ 
mente nella stessa maniera; una tale indipendenza del metodo 
dal dispositivo interessato è uno dei punti di forza dell’approc¬ 
cio di Amiga allT/O. 

Questo articolo ha tentato di fare un po’ di luce su quell’ area 
mal documentata dell’ambiente di Amiga che è l’implementa- 
zione dei device e di chiarire come sia possibile un interfaccia¬ 
mento formalmente uniforme con un’ampia varietà di 
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C 


dispositivi, dalle tavolette digitalizzatrici ai plotter e alle Starti- /dimensione dello stack e priorità' per il processo 
panti laser. -• creeremo 


I programmi allegati a questo articolo sono stati sviluppati con 
il compilatore Manx Aztec C68k v3.60a e il debugger SDB. 


MYPROCSTACKSIZE EQU $400 

MYPROCPRI EQU 0 

; nome del mio device 
MYDEVNAME MACRO 

de.b 'mydev.device',0 

ENDM 


Listato 1 : mydev def.i 


Listato 2: asmsupp.i 


; mydev_def.i 

/ definizioni assembler per mydev.device 
; Storia: 

/ 88-05-16 creato 


asmsupp.i 
macro addizionali 

Storia : 

88-05-06 creato 


/offset delle funzioni del device rispetto alla base 

/della struttura CLEAR MACRO 


LIBINIT 


moveq 

#0, \1 

LIBDEF 

Dev BeginlO 

ENDM 


LIBDEF 

Dev AbortIO 



LIBDEF 

Dev Fune 

LINKSYS 

MACRO 



LINKLIB 

_LVO\l,\2 



ENDM 


MD NUMUNITS EQU 4 





CALLSYS 

MACRO 

/strutture dell'area dati del device mydev 

CALLLIB 

_LVO\l 

STRUCTURE MyDev,LIB_SIZE 

ENDM 


ULONG 

md ExecBase 



ULONG 

md DosBase 

XLIB 

MACRO 

ULONG 

md SegList 

XREF 

_LVO\l 

UBYTE 

md Flags 

ENDM 


UBYTE 

md pad 



STRUCT 

md_Units,MD NUMUNITS*4 



LABEL 

MyDev Sizeof 





Listato 3: mydev.asm 

STRUCTURE MyDevMsg,MN_SIZE 



APTR 

mdm Device 



APTR 

mdm Unit 



APTR 

mdm Iob 



LABEL 

MyDevMsg Sizeof 

; mydev.data 

— esempio del codice 


STRUCTURE MyDevUnit,UNIT_SIZE 
UBYTE mdu_UnitNum 
UBYTE mdu_pad 

STRUCT mdu_Msg,MyDevMsg_Sizeof 
APTR mdu_Process 
LABEL MyDevUnit_Sizeof 


Esempio di come si possa costruire un device di 
sistema 

Storia : 

88-05-17 creato 
88-11-06 versione finale 


/flag dì stato per le unit fermate 
BITDEF MDU,STOPPED,2 


assemblaggio: as -c -d -1 -isys2:asm mydev 

link: In -o mydev.device mydev sys3:lib/cl.lib 
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; Nota: usate il modello large code e large data 
; senza modulo di startup 

; (.begin per Manx, startup.obj per Lattice) 


SECTION 

section 

NOLIST 


INCLUDE 

"exec/types.i" 

INCLUDE 

"exec/nodes.i" 

INCLUDE 

"exec/lists.i" 

INCLUDE 

"exec/alerts.i" 

INCLUDE 

"exec/resident.i" 

INCLUDE 

"exec/initializers.i 

INCLUDE 

"exec/memory.i" 

INCLUDE 

"exec/libraries.i" 

INCLUDE 

"exec/devices.i" 

INCLUDE 

"exec/io.i" 

INCLUDE 

"exec/ables.i" 

INCLUDE 

"exec/errors.i" 

INCLUDE 

"libraries/dos.i" 

INCLUDE 

"libraries/dosextens 

INCLUDE 

"asmsupp.i" 

INCLUDE 

"mydev def.i" 

LIST 



; definizioni e riferimenti esterni 


XLIB SetTaskPri 

INT_ABLES 

DEVINIT 

DEVCMD MYDEVCMD 
DEVCMD MYDEV END 


La prima locazione eseguibile. Restituisce un 
errore nel caso che qualcuno cerchi di eseguire il 
device come se fosse un preogramma 


DevStart: 

CLEAR dO 
rts 


definizioni ed EQU varie 


/priorità' della libreria 
MYPRI EQU 0 

/major number della versione 
VERSION EQU 1 

/una revisione particolare. Identifica in modo 
/univoco la libreria 
REVISION EQU 1 


XDEF 

Devlnit 






XDEF 

Open 

;Una struttura 

romtag. 



XDEF 

Close 

;'exec' e 'ramlib 

' ricercano questa struttura 

XDEF 

Expunge 

/durante la fase 

di caricamento 

per scoprire, per 

XDEF 

ExtFunc 

/esempio, da quale punto debba partire 1 

esecuzione. 

XDEF 

myName 

/Ciò' e' equivalente alla struttura C Resident. 

XDEF 

BeginlO 











XDEF 

AbortIO 






XDEF 

DevFunc 

initDevDescrip 


/stuttura RT,0 




dc.w 


RTC_MATCHWORD 

/UWORD 


XREF 

AbsExecBase 

RT_MATCHWORD 







de. 1 


initDevDescrip 

/ APTR 

RT_MATCHTAG 

XLIB 

OpenLibrary 

de. 1 


EndDevCode 

/ APTR 

RT_ENDSKIP 

XLIB 

CloseLibrary 

dc.b 


RTF_A'JTOINIT 

/UBYTE 

RT_FLAGS 

XLIB 

Alert 

dc.b 


VERSION 

/UBYTE 

RT_VERSION 

XLIB 

FreeMem 

de. b 


NT_DEVICE 

/UBYTE 

RT_TYPE 

XLIB 

Remove 

de. b 


MYPRI 

/UBYTE 

RT_PRI 

XLIB 

FindTask 

de. 1 


myName 

/APTR 

RT_NAME 

XLIB 

AllocMem 

de. 1 


DevIdString 

/APTR 

RT_IDSTRING 

XLIB 

CreateProc 

de. 1 


Devlnit 

/ APRT 

RT_INIT 

XLIB 

PutMsg 




/LABEL 

RT_SIZE 

XLIB 

RemTask 






XLIB 

ReplyMsg 

/nome del mio 

device 



XLIB 

Signal 

myName 

MYDEVNAME 



XLIB 

GetMsg 






XLIB 

WaitPort 






XLIB 

AllocSignal 







Ho 
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/Identificatore del device tag usato per supportare 
;il device. 

; Il formato e' : 

; 'nome versione.revisione (dd mmm yyyy)', 

<cr>,<lf>,<null> 


DevIdString dc.b 'mydev 1.0 (11 August 

1988)',13,10,0 

; nome della dos library da aprire 
dosName DOSNAME 

/forza l'allineamento su word 
ds. w 0 


/romtag specifica , 'RTF_AUTOINIT". Il campo RT_INIT 
/punta alla tabella seguente. Se RTF_AUTOINIT non e' 
/impostato, allora RT_INIT punta a una routine di 
/inizialilzzazione che deve essere eseguita. 

/Questi dati sono usati dal programma di caricamento 
/come parametri per MakeLibrary() 


Devlnit: 

de. 1 
de. 1 


de. 1 


de. 1 


MyDev_Sizeof 

funcTable 


dataTable 


initRoutine 


/dimensione dei dati 
/puntatore agli 
/inizializzatori 
/delle funzioni 
/puntatore agli 
/inizializzatori 
/dei dati 
/routine da 
/eseguire 


Questa tabella inizializza le strutture dati 
statiche. Il formato e' specificato nelle pagine 
del manuale RKM relative a exec/InitStruct. Il 
primo argomento e' l'offset rispetto alla base 
della libreria del device. Il secondo e' il valore 
da porre in quella cella. La tabella e' terminata 
con un NULL. 


dataTable: 


INITBYTE 

LN_TYPE,NT_DEVICE 

INITLONG 

LN NAME,myName 

INITBYTE 

LIB_FLAGS, 

LIBF_SUMUSED!LIBF_CHANGED 

INITWORD 

LIB_VERSION,VERSION 

INITWORD 

LIB_REVISION,REVISION 

INITLONG 

LIB_IDSTRING,DevIdString 

de. 1 

0 


Questa e' la routine di inizializzazione - viene 
chiamata dopo che il device e' stato allocato. 

Se restituisce un valore diverso da zero, il device 
verrà' collocato nella lista dei device mantenuta 
dall'Exec 


initRoutine: / (d0:dev.ptr. A0:seg.list) 

/mette il puntatore al device in A5 
move.1 a5,-(sp) 

move.1 d0,a5 

/salva il puntatore a exec 

move.1 a6,md_ExecBase(a5) 

/salva il puntatore alla segment list 
move.l aO,md_SegList(a5) 


/Tabella degli indirizzi delle funzioni mydev 


funcTable: 

/routine standard di sistema - devono essere 
/sempre incluse 

dc.l Open 

dc.l Close 

de.1 Expunge 

dc.l ExtFunc 

/definizioni per il mio device 
dc.l BeginlO 

dc.l AbortIO 

/funzioni del mio device 
de.1 DevFunc 

/marcatore di fine tabella 
dc.l -1 


/apre la dos.library 

lea dosName(pc),al 

CLEAR dO 

CALLSYS OpenLibrary 


move.l dO,md_DosBase(a5) 

bne.s init DosOK 


/non può' aprire 
ALERT 


la dos.library 
AG_OpenLib!AO_DOSLib 


init_DosOK: 

/genera i dati statici di cui ha bisogno 

/le inizializzazioni specifiche del device devono 
/essere poste qui. 


move.l a5,d0 

move.l (sp)+,a5 


m 


‘b 
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I comandi di interfacciamento del sistema iniziano 
qui. Le chiamate a OpenDevice()/CloseDevice/ 
RemDeviceO vengono tradotte in chiamate alle 
routine Open/Close/Expunge. Il puntatore alla base 
della libreria del device si trova in A6. Il task 
switching e' stato disabilitato con Forbid/Permit. 


Open : 


movem.1 

move.1 


; device: A6 
;iob: Al 
;unitnum: DO; 
;flags: DI 
d2/a2-a4,-(sp) 

al, a2 


: salva l'iob 


; lo unit number e' nell'intervallo 
moveq #MD_NUMUNITS,d2 

cmp.1 d2, dO 

bcc.s OpenError 


; la unit e' già' inizializzata 
move.1 dO, d2 


;unit number 
; oltre 

; 1'intervallo 


; salva lo unit 
;number 


lsl.l #2,dO 

lea.l md_Units(a6,dO.1),a4 

move.1 (a4),dO 

bne.s OpenUnitOK 

;prova a ottenere una unit 
bsr InitOnit 

; 1'inizializzazione e' OK 
move.1 (a4),dO 


beq. s 

OpenUnitOK: 

move.1 


move.1 


OpenError 


dO, a3 


dO,IO UNIT(a2) 


/puntatore alla 
;unit in a3 


;incrememta il contatore di unit aperte 
addq.w #1,LIB_OPENCNT(a6) 

addq.w #1,UNIT_OPENCNT(a3) 

/nessun expunge ritardato permesso 


bclr 


OpenEnd: 

movem.1 
rts 

OpenError : 

move.b 
bra. s 


#LIBB_DELEXP,md_Flags(a6) 


(sp)+,d2/a2-a4 


#IOERR_OPENFAIL,IO_ERROR(a2) 
OpenEnd 


Se c'e' un errore il campo IO_ERROR della struttura 
devìce request e' impostato, altrimenti nel campo 
IO_UNIT si trova un puntatore alla device unit. 


Se il device non e' piu' aperto, dose restituisce 
la segment list se il flag di expunge ritardato e' 
impostato; altrimenti restituisce NULL. 


Close: /(device: A6, iob: Al) 

movem.1 a2-a3,-(sp) 

move.l al,a2 

move.1 IO_UNIT(a2),a3 

/l'iob non può' essere usato nuovamente 
moveq.1 #-l,dO 

move.l dO,IO_UNIT(a2) 

move.l dO,IO_DEVICE(a2) 

/la unit e' ancora in uso 

subq.w #l,UNIT_OPENCNT(a3) 

bne.s CloseDevice 


bsr 


ExpungeUnit 


CloseDevice: 

,-decrementa il contatore delle aperture del 
; device 

subq.w #l,LIB_OPENCNT(a6) 

/qualcuno ha il device aperto 
bne.s CloseEnd 

;c'e' qualche expunge ritardato 

btst #LIBB_DELEXP,md_Flags(a6) 

beq.s CloseEnd 

/esegue 1'expunge 

bsr Expunge 


CloseEnd: 


movem.1 
rts 


(sp)+,a2-a3 


Se il device non e' piu' aperto, Expunge ritorna la 
segment list del codice del device. Altrimenti 
viene impostato il flag di expunge ritardato e 
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m r 


/viene restituito 

NULL in DO . 

rts 






V x • n u / 

' 


movem . 1 

d2/a5-a6, - (sp) 

/InitUnit inizializza una device unit e fa partire 

move . 1 

a6, a5 

;lo unit task associato. 

move . 1 

md ExecBase(a5) , a6 



' 


;il device e' 

aperto 

InitUnit: 

/ unit number: D2 

tst . w 

LIB_OPENCNT(a5) 


/ scratch: A3 

beq 

1$ 

movem.1 

/ devptr: A6) 
d2-d4,-(sp) 

; ancora aperto 

- imposta il flag di expunge 



; ritardato 


/alloca la memoria per la unit 

bset 

#LIBB_DELEXP,md_Flags(a5) 

move . 1 

#MyDevUnit Sizeof,dO 

CLEAR 

dO 

move . 1 

#MEMF_PUBLIC!MEMF_CLEAR,di 

bra . s 

ExpungeEnd 

LINKSYS 

AllocMem,md ExecBase(a6) 

1$: 


tst . 1 

dO 

;OK, rimuove il device - memorizza seglist in d2 

beq 

InitUnitEnd 

move . 1 

md SegList(a5) , d2 

move . 1 

dO, a3 

/unlink dalla 

lista dei device 

move . b 

d2,mdu UnitNum(a3) /inizializza 

move . 1 

a5, al 


; lo unit 

CALLSYS 

Remove 


/number 



move . b 

#NT MSGPORT,LN TYPE(a3) 

/Chiusure specifiche del device devono essere 

;I1 processo 

unit viene iniziato qui. Si imposta 

; poste qui 


/il flag della message port del processo a 

/ 


/PA IGNORE finche' il flag non viene resettato 



/dal nuovo processo. 

/chiude la dos 

library 

move . 1 

#MYPROCSTACKSIZE,d4 /imposta 

move . 1 

md DosBase(a5) , al 


;la dimensione 

CALLSYS 

CloseLibrary 


/dello stack 



move.1 

#myproc seglist,d3 /imposta 

/libera la memoria allocata 


/la segment 

CLEAR 

dO 


/ list 

move.1 

a5, al 

lsr. 1 

#2,d3 /cambia il 

move.w 

LIB NEGSIZE(a5),dO 


/puntatore 




/ BCPL 

sub. 1 

dO, al 

moveq 

#MYPROCPRI,d2 /imposta la 

add.w 

LIB_POSSIZE(a5),dO 


/priorità' del 




/processo 

CALLSYS 

FreeMem 

move.1 

#myName,di 



LINKSYS 

CreateProc,md DosBase(a6) 

/imposta il valore di ritorno 

tst. 1 

dO 

move.1 

d2, dO 

beq 

InitUnitFreeUnit 

ExpungeEnd: 


/imposta le strutture unit per il nuovo processo 

movem.1 

(sp)+,d2/a5-a6 

move.1 

a 

o 

&> 

o 

rts 


move.1 

dO,mdu Process(a3) 


;ExtFunc mette solamente 0 nel registro DO 


ExtFunc: 


CLEAR 


dO 


lea -pr_MsgPort(aO) , aO 

move.b #PA_IGNORE,MP_FLAGS(a3) 

move.1 aO,MP_SIGTASK(a3) 

;manda il messaggio di inizio al nuovo processo 
lea mdu_Msg(a3) , al 

move.1 a3,mdm_Unit(al) 

move.l a6,mdm_Device(al) 

move.b #NT MESSAGE,LN TYPE(al) 
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move.1 

dO, aO 

/delle routine 

che implementano i 

comandi 


LINKSYS 

PutMsg,md ExecBase(a6) 

/Gli indirizzi 

sono acquisiti con 

la chiamata 




/ExecutelO 




/marca la unit come pronta per l'esecuzione 





move.b 

mdu UnitNum(a3),dO 





lsl.l 

#2, dO 

cmdTable: 




move.1 

a3,md Units(a6,dO.1) 

de. 1 

Invalid 

,-$00000001 bit 

0 



de. 1 

Reset 

,-$00000002 

1 

InitUnitEnd: 


de. 1 

Read 

,-$00000004 

2 

movem.1 

(sp)+, d2-d4 

de. 1 

Write 

,-$00000008 

3 

rts 


de. 1 

Update 

,-$00000010 

4 



de. 1 

Clear 

;$00000020 

5 

; errore - libera 

la struttura unit allocata in 

de. 1 

Stop 

,-$00000040 

6 

/precedenza 


de. 1 

Start 

;$00000080 

7 

InitUnitFreeUnit: 


de. 1 

Flush 

,-$00000100 

8 

bsr 

FreeUnit 

de. 1 

Custom 

,-$00000200 

9 

bra. s 

InitUnitEnd 







/Quali comandi 

non devono essere 

accodati 


;libera la memoria allocata per la unit 

IMMEDIATE EQU 

$000001c2 

;Flush|Start( 


FreeUnit: / 

(unitptr: A3, deviceptr: A6) 



/MyStop|MyReset 



move.1 
move.1 
LINKSYS 
rts 


ExpungeUnit: 

move.1 


a3, al 

#MyDevUnit_Sizeof, dO 
FreeMem,md ExecBase(a6) 


;(unitptr:A3, deviceptr:A6) 
d2, -(sp) 


BeginlO - tutto l'IO arriva attravero questa 
routine. L'IO viene accodato o eseguito 
immediatamente 


BeginlO: 


; rimuove il task della unit - a questo punto il 
; contatore delle unita' aperte vale zero. Quindi 
;e' abbastanza sicuro. 

move.l mdu_Process(a3) , al 

lea -(pr_MsgPort)(al),al 

LINKSYS RemTask,md_ExecBase(a6) 

; salva lo unit number 
CLEAR d2 

move.b mdu UnitNum(a3),d2 


move.1 


(iob:Al, device:A6) 
a3,-(sp) 


; copia la device unit 

move.l IOJUNIT (al) , a3 

;I1 comando di IO e' previsto 
CLEAR dO 

move.w IO_COMMAND(al),dO 

cmp.w #MYDEV_END,dO 

bcc.s BeginIO_BadCmd 


/libera la struttura unit 
bsr FreeUnit 

/pulisce lo unit vector nella struttura del 
/device 


DISABLE 


aO 


/gestisce i comandi con il quick flag impostato 
btst #IOB_QUICK / IO_FLAGS(al) 

bne.s BeginIO_Immediate 


lsl.l 

#2,d2 



clr.l 

md Units(a6,d2.1) 

/gestisce tutti 

i comandi immediati 



move.w 

♦IMMEDIATE,di 

move.1 

(sp)+, d2 

btst 

dO, di 



bne. s 

BeginlO Immediate 

rts 





/I comandi specifici del device cominciano qui 


/smdTable - qui vengono mantenuti gli indirizzi 


/l'unita' e' ferma - se e' cosi' accoda il 
/messaggio 

btst #MDUB_STOPPED,UNIT_FLAGS(a3) 

bne.s BeginIO_QueueMsg 

/non e' un comando immediato - il device e' 

/occupato 

bset #UNITB_ACTIVE,UNIT_FLAGS(a3) 

beq.s BeginIO_Immediate 
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se la richiesta era immediata o se era stata fatta 


/accoda la richiesta - marca il device come 

/partire dal task della unit. 

/avente bisogno 

dell'attenzione del task 





/pulisce il quick flag 





Terminatelo: 

(iob:Al, unitptr:A3, devptr:A6) 

BeginlO QueueMsg: 


CLEAR 

dO 

bset 

#(JNITB_INTASK,UNIT_FLAGS(a3) 

move.w 

IO COMMAND(al) , dO 

bclr 

#IOB_QUICK,IO_FLAGS(al) 

move.w 

«IMMEDIATE, di 



btst 

dO, di 

ENABLE 

a0 

bne. s 

TerminateIO_Immediate 

move. 1 

mdu Msg(a3),a2 

/spegne il bit active? 

move.1 

al,mdm Iob(a2) 

btst 

«UNITBINTASK,UNIT_FLAGS(a3) 

move.1 

a2, al 

bne. s 

Terminatelo Immediate 

move.1 

mdu Process(a3),aO 



LINKSYS 

PutMsg,md ExecBase(a6) 

/non c'e' altro 

lavoro per il task 

bra. s 

BeginlO End 

bclr 

#UNITB_ACTIVE,UNIT_FLAGS(a3) 

BeginlO Immediate: 


Terminatelo Immediate: 

ENABLE 

aO 

/Se il bit quick 

io e' impostato ritorna al 

bsr 

ExecutelO 

/chiamante senza 

un messaggio di risposta 



btst 

#IOB_QUICK,IO_FLAGS(al) 

BeginlO End: 


bne. s 

Terminatelo End 

move.1 

(sp)+,a3 



rts 


LINKSYS 

ReplyMsg,md ExecBase(a6) 

BeginlO BadCmd: 


Terminatelo End: 


move.b 

#IOERR_NOCMD,IO_ERROR(al) 

rts 


bra. s 

BeginlO End 




ExecutelO fa l'effettivo dìspatching delle 
richieste. A3 contiene il puntatore alla unit, A6 
quello al device e Al ha la richiesta di IO. 


ExecutelO: ;(iob:Al, unitptr:A3, devptr:A6) 


move. 1 

a2, -(sp) 

move. 1 

al, a2 

move.b 

#0,IO_ERROR(a2) /pulisce il 

/campo dell'errore 

CLEAR 

dO 

move.w 

IO_COMMAND(a2) , dO 

lsl.l 

#2,d0 /byte offset 

/nella tabella 

lea 

cmdTable(pc),aO 

move.1 

0(aO, dO.w),aO 

jsr 

(aO) 

move. 1 

rts 

(sp)+, a2 


AbortIO - Non e' implementata 


AbortIO: ; (iob:Al, device:A6) 

rts 

AbortIO_End: 

rts 


Le funzioni che implementano i comandi del device 
iniziano qui. Viene adottato il seguente formato 
per i registri. 

Al - ptr. all'io request block 
A2 - un altro ptr.all’iob 
A3 - ptr. alla struttura unit 
A6 - ptr. alla struttura device 


Invalid - ritorna semplicemente IOERR_NOCMD nel 
campo io_error 


/Terminatelo manda indietro la richiesta al 
/chiamante. Il device non e' impostato come inattivo 


Invalid: 

move.b 
move.1 


#IOERR_NOCMD,IO_ERROR(al) 
#0,IO_ACTUAL(al) 


[Hi 


‘t] 
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bsr Terminatelo 

rts 


l'IO in attesa, senza ritornare finche' non ha 
finito 


Reset - Non e' implementato Update: 

- bra 


Invalici 


Reset : 


move. 1 
rts 


#0,10 ACTUAL(al) 


Clear - non implementato - dovrebbe pulire tutti i 




/buffer interni 




Clear: 





;Read - agisce come 

un infinita sorgente di 1. 

bra 

Invalid 

/Restituisce il numero 1 nel buffer 







Read: 


; Stop - ferma il 

trattamento di tutte le richieste 

move.1 

IO_DATA(al) , aO 

;di IO finche' non viene ricevuto il comando Start 

move.1 

IO_LENGTH(al) , dO 





CLEAR 

d2 



move 

#0,ccr 

Stop: 




bset 

#MDUB_STOPPED,UNIT_FLAGS(a3) 

; gestisce read 

con lunghezza zero 

move.1 

#0,IO_ACTUAL(al) 

beq. s 

ReadEnd 

bsr 

Terminatelo 



rts 


; copia il dato 




CLEAR 

di 



/valore in DI per la copia 





move.l #1 

di 

/Start - fa ripartire un task di una unit 

ReadLoop: 


/precedentemente 

fermato 




move.b 

di, (a0) + 



add. 1 

#1, d2 

Start : 


sub. 1 

#1, dO 

bsr 

InternalStart 

bne. s 

ReadLoop ; se Z non e' 

move.1 

a2, al 


; settato (dO!=0) 

move.1 

#0,IO_ACTUAL(al) 



bsr 

Terminatelo 

ReadEnd: 


rts 


move.1 

d2,IO ACTUAL(al) 



bsr 

Terminatelo 

InternalStart: 


rts 


/riattiva il 

trattamento delle richieste 



bclr 

#MDUB_STOPPED, UNIT_FLAGS(a3) 



/segnala al task di ripartire 



/Write - fa un dump 

del buffer della richiesta. 

move.1 

a3, al 

,-Restituisce il numero dei byte scritti nel campo 

CLEAR 

dO 

;io actual 


CLEAR 

di 





move.b 

MP_SIGBIT(a3) , di 

Write: 


bset 

di, dO 

move. 1 

IO_LENGTH(al),IO_ACTUAL(al) 

LINKSYS 

Signal,md ExecBase(a6) 

bsr 

Terminatelo 



rts 


rts 



,-Update - non implementato - dovrebbe scrivere tutto ;Flush - restituisce tutte le richieste in attesa ai 


no 
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■ E 


/rispettivi chiamanti. 


Flush: 

movem.1 

d2/a6,-(sp) 


move.1 

md ExecBase(a6) , a6 


bset 

sne 

#MDUB STOPPED,UNIT 

d2 

_FLAGS (a3) 

FlushLoop: 

/va in loop 

move.1 

CALLSYS 

finche' non ci sono piu 
a3, aO 

GetMsg 

richieste 

tst. 1 

beq. s 

dO 

FlushEnd 


move.1 

move.b 

CALLSYS 

dO, al 

#IOERR_ABORTED,IO_ERROR(al) 
ReplyMsg 

bra. s 

FlushLoop 


FlushEnd: 

move.1 

movem.1 

d2, dO 

(sp)+,d2/a6 


tst. b 

beq. s 

dO 

1$ 


bsr 

InternaiStart 


1$: 

move.1 

bsr 

a2, al 

Terminatelo 


rts 



/Custom - comando custom - non fa molto 

Custom: 

bsr Terminatelo 

rts 

;Le funzioni del 

device iniziano qui 



/DevFunc - restituisce il contatore delle aperture 
/per una unit specifca 


DevFunc: ;(devptr:A6, unit no.:D0) 

move.1 a3,-(sp) 

;unit number nell'intervallo 
move.1 #MD_NUMUNITS, d2 

cmp .1 d2, dO 

bcc.s DevFuncError 

lsl.l #2, dO 

move.l md_Units(a6, dO.1) , a3 

cmp.l #0,a3 

beq.s DevFuncE»>ror 

move.w UNIT OPENCNT(a3),dO 


DevFuncExit: 

move.1 
rts 


(sp)+,a3 


DevFuncError: 

move.l #-l,dO 

error 

bra.s DevFuncExit 


; f lag 


;I1 processo della unit del device inizia qui 

/Viene usato un processo in modo che le richieste 
/accodate possano essere trattate in un momento 
/successivo. 


Questo pezzo imbroglia il DOS - abbiamo alterato il 
codice in memoria usando LoadSeg. Usando Loadseg il 
segmento ha il seguente prefisso: 

<seg. lenXptr . to next seg.> 

Abbiamo impostato la segment list qui, e il 
processo 

/inizia al primo indirizzo dopo la segment list 


MyDevProcStart: 

CNOP 0,4 

word 

de. 1 

MyDevProcSeglist: 
de. 1 

segmento 


/allineamento su long 
16 /lunghezza del segmento 

0 /ptr. al prossimo 


Il processo inizia qui 


MyDevProcBegin: 

move.1 


AbsExecBase,a6 


m 


ti 
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■ r 


/aspetta il 

messaggio di startup 

btst 

#MDUB_STOPPED,UNIT_FLAGS(a3) 

sub. 1 

al, al 

bne. s 

MyDevProcMainLoop 

CALLSYS 

FindTask 



move.1 

dO, aO 

/setta il flag 

active del processo - quindi 

move.1 

dO, a 4 

/vengono accodati i messaggi 

lea 

pr MsgPort(aO),aO 

bset 

#UNITB_ACTIVE,UNIT_FLAGS(a3) 

move.1 

aO, d4 

beq.s 

MyDevProcMainLoop 

CALLSYS 

WaitPort 





MyDevProcNextMessage: 

; prende il 

messaggio dalla msg port - msgport e' 

/prende la prossima richiesta 

/marcata con PA IGNORE 

move.1 

d4,a0 

move.1 

dO, al 

CALLSYS 

GetMsg 

move.1 

dO, d2 

tst. 1 

dO 

CALLSYS 

Remove 

beq. s 

MyDevProcUnlock /messaggio? 

/prende i parametri necessari 

/handle thè request 

move.1 

d2,a2 

move.1 

dO, a2 

move.1 

mdm Device(a2),a5 /a5 e' il 

move.1 

d3,a3 /MyDevUnit ptr. 


/nostro nuovo 

move.1 

mdm Iob(a2),al /iob ptr. 


/device 

exg 

a5, a6 

move.1 

mdm Unit(a2),a3 

bsr 

ExecutelO 



exg 

a5, a6 

move.1 

a5,d5 /salva il device ptr. 



move.1 

a3,d3 /salva lo unit ptr. 

bra. s 

MyDevProcNextMessage 

/alloca un 

segnale 

/non ci sono altri messaggi - possiamo aspettare 

moveq 

#-l,dO /-I e': nessun 

/per altri 



/segnale del tutto 

MyDevProcUnlock: 


CALLSYS 

AllocSignal 

and.b 

#$ff&(UNITB ACTIVE!UNITB INTASK), 




UNIT_FLAGS(a3) 

move.1 

d3,a3 /recupera lo unit 

bra 

MyDevProcMainLoop 


/ptr. 



move.b 

dO,MP SIGBIT(a3) 

/arriviamo qui se fallisce 1'inizializzazione 

move.b 

#PA SIGNAL,MP FLAGS(a3) 

MyDevProcFail: 




bsr 

FreeUnit 



rts 


Il loop principale inizia qui. 



Procedura : 







- aspetta un 

- fa un lock 

messaggio alla porta 

del device - il task e' attivo e sta 

/Questa e’ la fine 

del codice del nostro device 



trattando 

le richieste 



- prende il 

messaggio - se non c'e' messaggio 

EndDevCode: 


fa un unlock del device 

END 


- chiama ExecutelO e tratta il messaggio 

- riprende da capo aspettando un messaggio 




bra. s 


MyDevProcCheckStatus 


Listato 4: add dev.c 


MyDevProcMainLoop: 

/aspetta un messaggio alla porta 

move.1 d4,a0 /MsgPort per 

/questo processo 

CALLSYS WaitPort 

MyDevProcCheckStatus: 

/il flag stopped del processo e' settato ? 
move.l d3,a3 


/a************************************************** 

* add_dev.c 

•k 

* Modulo utilizzato per aggiungere un device 

* dell'utente alla lista dei device mantenuta dal 

* sistema. Dopo aver aggiunto il device dell'utente 

* e' disponibile a tutti i programmi seguenti. 

•k 

* Storia: 
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■ C 


* 88-05-06 creato 

* compilazione: cc add_dev 

* link: In add_dev -le 


♦include <functions.h> 

♦include <exec/types.h> 

♦include <exec/libraries.h> 
♦include <exec/resident.h> 
♦include <exec/devices.h> 
♦include <libraries/dos.h> 
♦include clibraries/dosextens.h> 


ULONG segList, 
codeloc; 


struct Init { 

ULONG space; 
dati 

ULONG funcTable; 

ULONG dataTable; 
initStruct 


/* puntatore alla seglist BCPL */ 
/* puntatore alla locazione del 
codice */ 


/* dimensione dello spazio 
*/ 

/* ptr. alla tabella degli 
offset delle funzioni */ 
/* ptr. alla tabella 




ULONG initRoutine; /* ptr. alla library 

initRoutine */ 

} *init; 

struct Resident *devRes; /* ptr. all'area rom tag 

del device */ 

•ULONG space, funcTable, dataTable, initRoutine; 
struct Device *mydev; 


main() 

{ 

/* carica il segmento del device */ 
segList = (ULONG)LoadSeg("mydev.device"); 
if (segList==NULL) { 

printf("Non posso caricare mydev.device\n"); 
exit (0); 

} 

/* indirizzo dell'inizio del codice del device 

* in memoria, moltiplicate per 4 perche' 

* segList e' un puntatore BCPL */ 

codeloc = segList * 4; 

/* indirizzo dell'area residente rom tag */ 
devRes = (struct Resident *)(codeloc + 8); 


/* indirizzo della tabella di inizializzazione */ 
init = (struct Init *)devRes->rt_Init; 

/* estrae i dati dalla tabella di 
* inizializzazione */ 
space = init->space; 
funcTable = init->funcTable; 
dataTable = init->dataTable; 
initRoutine = init->initRoutine; 

/* inizializza il device */ 
mydev = (struct Device * ) MakeLibrary_(.funcTable, 

dataTable, initRoutine, space, segList); 

/* rende il device conosciuto al sistema */ 
AddDevice(mydev); 

printf("mydev.device aggiunto al sistema\n"); 


Listato 5: main.e 


/*************************************************** 

* main.e 

* 

* Programma di test per mydev.device 

* 

* Storia: 

* 88-09-11 creato 

* 

* compilazione: cc main 

* link: In main devfunc -le 


*********:* 


***★**************************•*****/ 


♦include <functions.h> 

♦include <exec/types.h> 

♦include <exec/libraries.h> 
♦include <exec/devices.h> 
♦include <exec/io.h> 

♦define CMD CUSTOM (CMD FLUSH+1) 


struct MsgPort *reply; 
struct IOStdReq *req; 

UBYTE dev_flag=0; 

UBYTE buff[10]; 

main() 

{ 

ULONG ret, unit, vai, no_open, DevFuncO, 
WORD j; 


/* crea la reply port */ 
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reply = CreatePort("my_raain_reply",0); } 

if (repiy==NULL) { 

printfC'Non posso creare la reply port\n"); } 

cleanup(); 


/* crea la io request */ 
req = (struct IOStdReq *)CreateStdIO(reply); 
if (req==NULL) { 

printfC'Non posso creare la IO request\n"); 
cleanup(); 

) 

/* apre il device di prova */ 
ret = OpenDevice("raydev.device",0L,req,0L); 
if (ret!=NULL) ( 

printfC'Non posso aprire mydev.device\n"); 
cleanup(); 

} 

dev_flag = 1; 


Listato 6: devfunc.asm 


devfunc.asm 

routine di interfacciamento tra il programma C e 
la funzione in mydev.device 

Storia : 

88-09-11 creato 
assemblaggio: as devfunc 


/* legge qualcosa */ 
req->io_Command = CMD_READ; 
req->io_Data = (APTR)buff; 
req->io_Length = (ULONG)sizeof(buff); 

DoIO(req); 

printf("io_Actual=%ld\n",req->io_Actual); 

/* ora prova i nostri comandi custom */ 
req->io_Command = CMD_CUSTOM; 

BeginlO(req); 

printf("io_Actual=%ld\n",req->io_Actual); 

/* chiama la nostra funzione custom */ 
unit = 0L; 

no_open = DevFunc(req,unit); 
printf("no_open=%ld\n",no_open); 

cleanup(); 


/*************************************************** 

* cleanup() - rilascia ogni cosa che sia stata 

* aperta o allocata 
**************************************************/ 


cleanup() 

{ 

if (dev_flag) ( 
CloseDevice(req); 

} 

if (req) { 

DeleteStdIO(req); 

} 

if (reply) { 

DeletePort (reply); 


NOLIST 

INCLUDE 

"exec/types.i" 

INCLUDE 

"exec/libraries.i 

INCLUDE 

"exec/nodes.i" 

INCLUDE 

"exec/lists.i" 

INCLUDE 

"exec/io.i" 

INCLUDE 

"exec/devices.i" 

INCLUDE 

"asmsupp.i" 

INCLUDE 

"mydev def.i" 

LIST 

XREF DevFunc 


Sequenza di chiamata C: 

no_open = DevFunc(req,unit) 
registri: DO A0 DO 

LONG no_open, unit; 
struct IOStdReq *req; 


DevFunc: 

; recupera i dati della chiamata dallo stack 
move.1 4(sp),aO 

move.1 8(sp),dO 

; chiama la funzione del device 

LINKLIB Dev_Func,IO_DEVICE(aO) 

/ritorna al chiamante 
rts 

end 
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Fantastici games dall'universo di Amiga 

Rigorosamente originali j 

Garantiti dal marchio ■! ■ 


edicola 



























Aut. Min. Rich. 


NOVITÀ' ASSOLUTA IN EDICOLA 




Nuovissima, ricca e tutta a colori. GUIDA VIDEOGIOCHI 
ti aspetta in edicola con oltre 60 giochi recensiti, i commenti, 
le curiosità, i trucchi e le novità da tutto il mondo. 

E, in più, partecipi al grande 
concorso riservato ai 
fedeli lettori 

di GUIDA VIDEOGIOCHI. 

















